This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug gdb/20287] X32 and "gdb_static_assert (sizeof (nat_siginfo_t) == sizeof (siginfo_t))"


https://sourceware.org/bugzilla/show_bug.cgi?id=20287

--- Comment #31 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Jeffrey Walton from comment #29)
> (In reply to Walfred Tedeschi from comment #28)
> > Kernel is then 64bit.
> > 
> > With a set of libraries we could also have 64bit applications running on the
> > x32 systems, or?
> > 
> > Would that be an use case?
> 
> You will likely experience this issue on multiple platforms, and not just
> X32. Its a problem incumbent to the 32-bit data models (ILP32), and it
> should resurface on ARM with Aarch32 execution environments on AArch64.
> 
> The data model is the reasons applications are advised to use the pair
> {__ILP32__,__x86_64__}, {__ILP32__,__aarch64__}, etc when determining the
> execution environment.

One other use case to be aware of is this one... It bit me, and its why I
[mostly] know how to detect the execution environment...

Sun Studio and Clang always defines __ILP32__ when using a 32-bit data model.
It will be defined for i386, i686, etc. Its why __x86_64__, __arm64__,
__aarch64__, etc are needed to discriminate.

It also diverges from System-V amd64 ABI guides at
http://sites.google.com/site/x32abi/documents/abi.pdf. When I asked Clang devs 
about it, they stated they were not prohibited from defining __ILP32__ on
32-bit machines.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]