This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
elf/tst-protected1 failures on tilegx
- From: Chris Metcalf <cmetcalf at ezchip dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 10 Jul 2015 17:08:43 -0400
- Subject: elf/tst-protected1 failures on tilegx
- Authentication-results: sourceware.org; auth=none
- Authentication-results: sourceware.org; dkim=none (message not signed) header.d=none;
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:23
The elf/tst-protected1[ab] tests fail on tilegx, with the output
showing that the protected variables, which are expected to reference
the same memory in the main module and in the shared objects, don't:
`protected1' in main and moda doesn't have same address
`protected3' in main and moda doesn't have same address
`protected1' in main doesn't have the updated value
`protected1' in moda has the wrong value
`protected3' in main doesn't have the updated value
`protected3' in main doesn't have the updated value
It looks like the Elf stuff is all plausible for these variables,
e.g. for protected1 it is "GLOBAL PROTECTED" in tst-protected1moda.os,
and in the main object, protected1 is an undefined symbol, and the
relocations to it are those that you would normally see for building
up an address with absolute 16-bit chunks on tilegx:
0000000000000360 R_TILEGX_IMM16_X0_HW2_LAST protected1
0000000000000368 R_TILEGX_IMM16_X0_HW1 protected1
0000000000000370 R_TILEGX_IMM16_X0_HW0 protected1
Compiling some small test programs with an "extern int" reference in
the main module, satisfied in a shared object, seem to suggest that
the tilegx tool chain and rtld are doing the right thing:
- Build executable with default flags, shared object -fpic, no
protected: both main module and .so use the low-address value in the
main module for the symbol.
- As above, but protected: main module and .so each use different
addresses for the symbol.
- Build executable with -fpie, shared object -fpic: both main module
and .so use the high-address value in the .so.
This is the same on x86 (RHEL 6, gcc 4.4, binutils 2.20.51) and on
tilegx (same but binutils 2.21).
Confusingly, the main object in the glibc test is not apparently built
with -fpie, so I don't really even understand how the test expects the
address to be the same given the use of "protected".
I'm not clear on what this test is trying to show and the actual test
is a complicated collection of interacting shared objects and symbols,
so before trying to untangle that in any more detail, I wondered if
there was some obvious thing I was missing. H.J. or someone, help?
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com