On Thu, Oct 20, 2022 at 11:57 AM Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>
> For the a/b build, I start with all*config, then:
Yes, I have that part all figured out.
> For the code diff, I use:
>
> objdump --disassemble --demangle --no-show-raw-insn --no-addresses
This part I still hate.
Have you figured out any way to get objdump to actually show the
relocations in-place in the assembly?
Ie, instead of
call <will_become_orphaned_pgrp+0xbf>
R_X86_64_PLT32 debug_lockdep_rcu_enabled-0x4
just show it as
call debug_lockdep_rcu_enabled
to make the diff - when it exists - hugely more legible?
Because now any code changes will not just show the code changes, but
end up showing a lot of silly changes because the "+0xbf" changes.
I guess I'll just have to remove all of those hex constants anyway,
because they also show up for any jumps inside the functions.
I also explored trying to compare just the generates *.s files, but
that has its own set of problems, notably with gcc label numbering.
Plus they are harder to generate for the full tree with our standard
build rules (maybe there's some trick I haven't thought of to make gcc
keep the '*.s' files as it generates the '*.o' ones).
I do have something that "works", but it turns out to be very noisy,
because while gcc *often* generates almost identical code, then when
it doesn't it can be quite nasty.
When there is a *real* difference, having a nasty diff is fine. For
example, the arch/x86/events/intel/p4.c issue that Alexey found
generates huge differences, because gcc can just see that "ok, that's
never negative", and generates completely different code.
That's good.
But when there's some small change that just changes the offset, it's
just annoying, even with --no-addresses. The hex numbers can be edited
out, but then you have the nop padding changes etc etc.
So getting rid of that kind of pointless noise is just about all the
effort here.
Linus
