On Tue, 25 Mar 2025 11:01:41 -0700 (PDT) Steven Rostedt <[email protected]> wrote:
> 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. That sounds good to me. I didn't use CONFIG_FTRACE_SORT_STARTUP_TEST, but I manually verified the section was sorted by checking the ELF using a Python script. Maybe that is something we can consider adding as a build step in the future? Sahil On Tue, Mar 25, 2025 at 1:01 PM Steven Rostedt <[email protected]> wrote: > > 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
