[NOT AN ARM ONLY PB] String offset errors on evbarm 8.99 [PR 54159]

[tlaronde%polynum.com@localhost]

Reminder:

On Wed, Aug 07, 2019 at 08:35:09PM +0200, tlaronde%polynum.com@localhost wrote:
> Description: the linker complains about string offsets in .strtab that
> are pass the end of the section. This can be seen equally with a
> cross-linker or a native linker on earmv7hf.
> 
> How to reproduce: this is triggered by the use of the:
> 
> 	-Wl,-retain-symbols-file -Wl,./some_exported_list
> 
> This can be tested with dummy modules (the script joined allows to
> create a variable number of modules---the "from" and "to" decimal
> numbers of first and last letter---with an alphabetical letter as
> name, and as the name of a function inside the dummy; by default, it
> creates 'a' to 'd' C files; it suffices to exhibit the problems).

In fact, the problem is not linked to ARM v7, it is even not a
"-retain-symbols-file" problem: it is only because this option discards
a lot of string that GNU ld has now more chances to observe that the
offsets it reads are past the .strtab section.

It is more general but is unseen if object defined (exported)
symbols appear to have in the _.dynsym_ symbol table an offset
staying in the range of .strtab size.

bfd/elf-strtab.c emits only some strings (the longuest ones) and not
strings that appear to be substrings of the previous ones: the offsets
are given "inside" these longer strings.

=> This is why the symbol (in my test case) 'a' and 'd' were not visible
in the readelf(1) dump of the .strtab section since they are substrings
of "$a" and "$d" respectively. So there is no problem here.

The problem is this one:

bfd/elflink.c:/4227,4230/

  /* If this is a dynamic object, we always link against the .dynsym
     symbol table, not the .symtab symbol table.  The dynamic linker
     will only see the .dynsym symbol table, so there is no reason to
     look at .symtab for a dynamic object.  */

Actually, GNU ld uses the .dynsym symbol table and uses its offsets
to look at .strtab! And these offsets are incorrect since these offsets
are relative to another strings section, namely .dynstr!

Here are the details of my test case. You will see that the incorrect
offsets are actually the offsets of the exported (retained) symbols 'a',
'b', 'c', 'd' but in the .dynstr section:

========== BEGIN READELF .dynstr

String dump of section '.dynstr':
  [     1]  __deregister_frame_info
  [    19]  __register_frame_info
  [    2f]  __cxa_finalize
  [    3e]  a	/* dec: 62 */
  [    40]  puts
  [    45]  b   /* dec: 69 */
  [    47]  c   /* dec: 71 */
  [    49]  libc.so.12
  [    54]  _end /* dec: 84; "d" is substring at 87 */
  [    59]  libbanc.so.0

========== END READELF .dynstr

========== BEGIN GNU LD COMPLAINTS
/data/m/tmp/olimex/tooldir.NetBSD-8.0-amd64/armv7--netbsdelf-eabihf/bin/ld: libbanc.so: invalid string offset 87 >= 11 for section `.strtab'
/data/m/tmp/olimex/tooldir.NetBSD-8.0-amd64/armv7--netbsdelf-eabihf/bin/ld: libbanc.so: invalid string offset 71 >= 11 for section `.strtab'
/data/m/tmp/olimex/tooldir.NetBSD-8.0-amd64/armv7--netbsdelf-eabihf/bin/ld: libbanc.so: invalid string offset 62 >= 11 for section `.strtab'
/data/m/tmp/olimex/tooldir.NetBSD-8.0-amd64/armv7--netbsdelf-eabihf/bin/ld: libbanc.so: invalid string offset 69 >= 11 for section `.strtab'
========== END GNU LD COMPLAINTS

========== BEGIN .strtab CONTENTS

String dump of section '.strtab':
  [     1]  $a
  [     4]  $d
  [     7]  c
  [     9]  b

Can someone confirm this analyzis?
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C