elf/tst-protected1 failures on tilegx

elf/tst-protected1 failures on tilegx

[Chris Metcalf]

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

Re: elf/tst-protected1 failures on tilegx

[Szabolcs Nagy]

On 10/07/15 22:08, Chris Metcalf wrote:
> 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:
> 

yes, this also fails on aarch64 and possibly all
other archs except on x86 with latest gcc and
binutils, i have a fix for aarch64 and arm now,
but it needs a gcc, binutils and glibc change.

> `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.
> 

protected visibility means that the definition is
not overridden by other modules, but it can be
still visible and then the address should be the same.

so the shared object should use GOT lookup instead
of GOT relative or ABS access.

> - 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).
> 

binutils and gcc used to treat protected data in
shared objects as local so copy relocation against
it in the executable did not work.

gcc bugs and fix:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=221742

glibc bug and fix:
https://sourceware.org/bugzilla/show_bug.cgi?id=17711
https://sourceware.org/git/?p=glibc.git;a=commit;h=62da1e3b00b51383ffa7efc89d8addda0502e107

binutils fix:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f74839702efcea048ac61374b1539ae81e7c86cc

(i think the bugs should be reopened as it
affects other targets too)

> 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?
>