Re: [PATCH 1/3] x86: Separate out x86_regset for 32 and 64 bit

[Edgecombe, Rick P]

On Tue, 2022-03-15 at 19:48 -0700, Kees Cook wrote:
> On Tue, Mar 15, 2022 at 09:53:13PM +0000, Edgecombe, Rick P wrote:
> > On Tue, 2022-03-15 at 13:41 -0700, Kees Cook wrote:
> > > Have you verified there's no binary difference in machine code
> > > output?
> > 
> > There actually was a different in the binaries. I investigated a
> > bit,
> > and it seemed at least part of it was due to the line numbers
> > changing
> > the WARN_ON()s. But otherwise, I assumed some compiler optimization
> > must have been bumped.
> 
> Right, you can ignore all the debugging line number changes.
> "diffoscope" should help see the difference by section. As long as
> the
> actual object code isn't changing, you should be good.

What I did originally was objdump -D ptrace.o and diff that. Then I
slowly reduced changes to see what was generating the difference. When
I maintained the line numbers from the original version, and simply
converted the enum to defines, it still generated slightly different
code in places that didn't seem to connected to the changes. So I
figured the compiler was doing something, and relied on checking that
the actual constants didn't change in value.

This morning I tried again to figure out what was causing the
difference. If I strip debug symbols, remove the BUILD_BUG_ON()s and
reformat the enums such that the line numbers are the same below the
enums then the objdump output is identical.

I think what is happening in this debug stripped test, is that in the
call's to put_user(), it calls might_fault(), which has a __LINE__.

But even adding a comment to the base file has surprisingly wide
effects. It caused the __bug_table section table to get code generated
with different instructions, not just line numbers constants changing.

So I think there should be no functional change, but the binaries are
not identical.