This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc 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 locale/18960] New: s390: _nl_locale_subfreeres uses larl opcode on misaligned symbol


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.


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