public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/111464] New: Using DW_EH_PE_udata4 for amd64 non-pic breaks linking in some situations
@ 2023-09-18 18:39 john at feith dot com
2023-09-18 20:58 ` [Bug target/111464] " pinskia at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: john at feith dot com @ 2023-09-18 18:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111464
Bug ID: 111464
Summary: Using DW_EH_PE_udata4 for amd64 non-pic breaks linking
in some situations
Product: gcc
Version: 9.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: john at feith dot com
Target Milestone: ---
Created attachment 55924
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55924&action=edit
Patch for amd64 R_X86_64_32 relocation issue
While the following was observed using gcc 9.5.0 configured to use gas / ld
from binutils 2.39 the code in question seems to be unchanged in this respect
for the current gcc 13.2.0 release.
I bootstrapped gcc 9.5.0 on FreeBSD 13.2 (amd64) and used it to build various
other programs without issue. However building gdb 11.2 results in:
ada-exp.o: relocation R_X86_64_32 against symbol
`__gxx_personality_v0@@CXXABI_1.3' can not be used when making a PDE object;
Looking at the 64 bit assembly language generate from ada-exp.c shows:
.Lframe1:
.long .LECIE1-.LSCIE1 # Length of Common Information Entry
.LSCIE1:
...
.byte 0x3 # Personality (udata4)
.long __gxx_personality_v0
gas generates a R_X86_64_32 relocation for __gxx_personality_v0 and then ld
throws the error when attempting to link the various object along with the
shared libraries into the executable fails. The ld error comes from bfd
elf64-x86-64.c:
case R_X86_64_32:
if (!ABI_64_P (abfd))
goto pointer;
/* Fall through. */
...
/* Check relocation overflow as these relocs may lead to
run-time relocation overflow. Don't error out for
sections we don't care about, such as debug sections or
when relocation overflow check is disabled. */
Note also the FreeBSD rtld-elf also doesn't support R_X86_64_32 so it's just
as well that the binutils ld throw the error.
In gcc i386.c asm_preferred_eh_data_format has:
...
if (ix86_cmodel == CM_SMALL
|| (ix86_cmodel == CM_MEDIUM && code))
return DW_EH_PE_udata4;
return DW_EH_PE_absptr;
The intent is that for 64 bit small and (in the code case) medium model to
save some space by encoding the address using 4 bytes instead of the full
8 byte pointer. That may be fine in some cases (i.e. full static linking),
however break certain other mixes (i.e. the forementioned non-PIE gdb build
using a shared C++ library).
The attached change simply changes the non-PIC case to always encode the
full pointer. Note this should be an essentially no-op change for 32 bits.
The resulting 64 bit assembly language generate from ada-exp.c shows:
.Lframe1:
.long .LECIE1-.LSCIE1 # Length of Common Information Entry
.LSCIE1:
...
.byte 0 # Personality (absolute)
.quad __gxx_personality_v0
and allows the gdb build to produce a working executable.
This doesn't seem to be a FreeBSD platform specific issue per-say as the
binutils code that checks for R_X86_64_32 isn't platform specific.
ChangeLog:
Fri Sep 15 01:50:44 EDT 2023 John Wehle (john@feith.com)
* i386.c (asm_preferred_eh_data_format): Always use DW_EH_PE_absptr
when non-pic.
-- John Wehle
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-09-20 5:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-18 18:39 [Bug target/111464] New: Using DW_EH_PE_udata4 for amd64 non-pic breaks linking in some situations john at feith dot com
2023-09-18 20:58 ` [Bug target/111464] " pinskia at gcc dot gnu.org
2023-09-19 8:59 ` rguenth at gcc dot gnu.org
2023-09-20 5:18 ` john at feith dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).