On Tue, 25 Mar 2025 12:52:43 -0500 Sahil Gupta <[email protected]> wrote:
> On Tue, 25 Mar 2025 05:15:10 -0700 (PDT) > Steven Rostedt <[email protected]> wrote: > > > How important is it for you to build 64 bit kernels > > on 32 bit machines? > > Yeah I don't disagree at all, it is a fairly idiosyncratic thing to > do. There are some historical and business justifications for still > building 32-bit in the first place, but until we deduplicate the > kernel build, we will continue to have this issue. Note, that the regression is only the failure in the build of your setup. As your setup never supported sorting the mcount location at build time, that part is not the regression. > > > One solution may be to simply disable > > mcount sorting at build time when it is detected that the host is 32 bit > > and the target is 64 bit. > > We are currently doing this. I imagine the performance difference is > trivial but if we can sort at build time, we might as well. I have a > fairly simple alternate solution that isn't backporting all of those > patches. The core idea is to introduce another macro, parse_addr, that > is defined as > > # define parse_addr(buf) strtoull(buf, NULL, 16) > > when SORTTABLE_64 is defined and > > # define parse_addr(buf) strtoul(buf, NULL, 16) > > when it isn't. Seems like a fair thing to do considering unsigned long > long is guaranteed to be at least 64-bit and unsigned long is > guaranteed to be at least 32-bit. I can post the patch in a stable- > thread. I'm not against you doing that, but it is specific for your setup. If you do this, make sure to test it by enabling: CONFIG_FTRACE_SORT_STARTUP_TEST Which will verify that the table is indeed sorted at run time. There could be another bug that could make it build, but not sort it properly, and without that config, you may not know, but it will cause ftrace to not work properly. -- Steve
