This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug locale/18960] New: s390: _nl_locale_subfreeres uses larl opcode on misaligned symbol
- From: "koriakin at 0x04 dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sun, 13 Sep 2015 20:17:49 +0000
- Subject: [Bug locale/18960] New: s390: _nl_locale_subfreeres uses larl opcode on misaligned symbol
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=18960
Bug ID: 18960
Summary: s390: _nl_locale_subfreeres uses larl opcode on
misaligned symbol
Product: glibc
Version: 2.21
Status: NEW
Severity: normal
Priority: P2
Component: locale
Assignee: unassigned at sourceware dot org
Reporter: koriakin at 0x04 dot net
Target Milestone: ---
Created attachment 8603
--> https://sourceware.org/bugzilla/attachment.cgi?id=8603&action=edit
compiled setlocale.c exhibiting this issue
On s390, compiling setlocale.c for static libc with -O2 results in code that
applies larl instruction (basically, load address of symbol using PC-relative
offset) to symbol _nl_current_LC_CTYPE_used.
_nl_current_LC_TYPE_used is defined to be 1 (when corresponding object file is
included) or 0 (when undefined - it's weakly referenced. However, larl
instruction can only load even values - instructions on s390 are 2-byte aligned
and the instruction encodes offset to the target in 2-byte units. This means
it's impossible to properly relocate setlocale.o if the value happens to be set
to 1.
The GNU BFD linker for s390 doesn't bother to check if relocations fit or are
properly aligned. This results in effectively using a symbol value of 0 - ie.
the whole logic of the test is broken.
I ran into this issue while working on s390 port of GNU gold, which did
relocation verification and noticed the problem.
I'm not certain how to resolve this issue. It seems that larl works for
ordinary symbols because gcc aligns everything to 2 bytes anyway. I see the
symbols are already stuffed in a static const pointer array (and not directly
in code) in setlocale.c, but gcc seems to optimize right through it.
Perhaps the symbols could be defined to 2 instead of 1 to work around this
issue? (or a higher value in case some other crazy arch has a similiar issue).
In case your compilation of glibc doesn't exhibit this issue, I attach my
setlocale.o extracted from libc.a. This is FWIW a gentoo system with default
options.
--
You are receiving this mail because:
You are on the CC list for the bug.