On Tue, 25 Mar 2025 05:15:10 -0700 (PDT)
Steven Rostedt [off-list ref] 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.

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.

Sahil

On Tue, Mar 25, 2025 at 7:15 AM Steven Rostedt [off-list ref] wrote:

On Tue, 25 Mar 2025 07:58:36 -0400
Greg KH [off-list ref] wrote:

quoted

It's up to the maintainer of the subsytem as to what they wish to see
happen.  I will always defer to them as they are the ones that have to
deal with emails from users :)

Thanks Greg for the reply.

Now bringing the question to Sahil.

This looks to be broken in 5.17 (when the mcount sorting was added). And
you are now using 6.12. How important is it for you to build 64 bit kernels
on 32 bit machines?

Nobody noticed this for a long time. 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. I don't know how easy it is to detect that at
build time, as it needs to unset a kernel CONFIG option. Perhaps Kconfig
can detect that?

-- Steve