On Wed, Jan 18, 2023 at 5:33 AM Feng Tang <feng.tang@xxxxxxxxx> wrote:
>
> > Finally, your objdump version also does some horrendous decoding, like
> >
> > c13b3e29: 8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi
>
> I know little about these tools, and I tried objdump tool from
> Cent OS 9 (objdump version 2.35.2) and Ubuntu 22.04 (objdump version
> 2.38), they both dumped similar assembly. Please let me know if you
> want us to try other version of objdump.
It's fine - it just makes things even less legible than they already were.
I personally very seldom try to look at objdump output - I tend to do
things like
make mm/page_alloc.s
and look at the compiler-generated assembly instead. That ends up
generally being a lot more legible for various reasons, not the least
of which is the variable name commentary that the compiler also
outputs.
So objdump is kind of a last resort, and then you just have to deal
with the fact that its output format is very nasty.
> We modify the kconfig to disable GCOV and UBSAN, and the issue can't
> be reproudced in 1000 runs.
Ok, it does seem like this is a compiler bug, as per Vlastimil's decoding.
And the reason it happens on 32-bit is probably that we just have much
fewer registers available there, and the 64-bit GCOV counts then
complicate things even more, and then some interaction between that
and UBSAN just generates crazy code.
And it probably has very little compiler test coverage in real life anyway.
>From Vlastimil's decode, it does look like gcc has mixed up the
"update GCOV counts" with actual real values for "nr_pages", and is
using %eax for both things because of some register allocation
mistake.
So I think we can dismiss this one as a compiler bug. It might be good
to see if it happens with a newer version of gcc too, and even perhaps
post a gcc bugzilla entry, but since this probably isn't really a very
interesting config for real life, I'm not sure how interested people
are going to be.
Linus
