This is the mail archive of the 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]

elf/tst-protected1 failures on tilegx

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

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