Re: PATCH: Add x32 support to dynamic linker audit

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Thu, Mar 22, 2012 at 1:59 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> It is happening, but when compiling for x86 the x32 for x86-64 bits
>> aren't enabled by default.
>
> I see. ?It's somewhat odd that sysdeps/generic/ldsodefs.h lists many
> different arch-specific rather than just using sysdeps files to define the
> ones for the arch actually being built. ?Why is it that way?

I don't know.

I thought it had something to do with the way the dynamic loader used
the interface generically in machine-independent code.

That can't really be a good reason.

> My only guess is that it's just to have all the prototypes next to each
> other so that interface changes can easily be made en masse. ?But since
> this interface is already set, that doesn't make a lot of sense.

Agreed.

> While I don't think there would be any particular problem with the file
> declaring the x86_64/x32 names in i386 builds (since everything has an
> arch-specific name anyway), it seems a bit untidy for the public header.
> By the same token, it doesn't seem entirely right that x86_64 names are
> declared in an x32 build--at least for the function declarations, since
> no single compile could make use of both.
>
> When I spoke before I didn't realize that the issue is the i386 build where
> all the declarations in question are just unused cruft. ?For that purpose,
> I really don't think it matters what type names are used in the unusable
> declarations--neither set of names will ever be complete types anywhere in
> that build anyway.

Right, so in the non-x86_64/x32 build the definition of `struct La_x32_*'
doesn't match the true definition. I don't think this matters.

Only on x86-64 is there a question of bad debug information, but there
the bits/link.h has:

#define La_x32_regs La_x86_64_regs
#define La_x32_retval La_x86_64_retval

Which means that the `struct La_x32_regs;' is actually another forward
declaration of `struct La_x86_64_regs;'.

e.g. Afre pre-processing:
...
struct La_x86_64_regs;
struct La_x86_64_retval;
struct La_x86_64_regs;
struct La_x86_64_retval;
...

Thus the only place you have bad debug information is in a situation
where it doesn't matter.

When it does matter the types resolve to the right ones.

The user happily uses `struct La_x32_*' as they expect and everything works.

>> The alternative fix is to just enable them no matter what, since
>> ldsodefs.h is going to use *all* the audit interfaces.
>>
>> ... and the problem with enabling them all is writing them in
>> such a way that they are the same size no matter what.
>
> I don't follow this.

I was just mumbling on about possible reasons why the
interfaces might *all* be exposed in machine-independent
headers and the difficulty in exposing correct types
in such conditions.

Cheers,
Carlos.