Re: Crash regression for annota1.exp w/vDSO debuginfo [Re: [pushed] Re: [PATCH v6 0/2] enable target-async by default]

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Sun, 05 Oct 2014 16:00:39 +0200, Jan Kratochvil wrote:
> That message
> 	warning: section  not found in /usr/lib/debug/lib/modules/3.16.3-200.fc20.x86_64/vdso/vdso64.so.debug^M
> is does not seem to be right - the file looks OK to me - but that seems
> unrelated to this regression.  Going to check next what vDSO separate debug
> info problem it is.

The message happens only with the separate debug info installed but in fact
the bug can be seen even without the separate debug info installed.

kernel-3.16.3-200.fc20.x86_64
(gdb) info files
[...]
0x00007ffff7ffb120 - 0x00007ffff7ffb160 is  in system-supplied DSO at 0x7ffff7ffb000
                                          ^^
0x00007ffff7ffb160 - 0x00007ffff7ffb268 is .dynsym in system-supplied DSO at 0x7ffff7ffb000
0x00007ffff7ffb268 - 0x00007ffff7ffb2c6 is .dynstr in system-supplied DSO at 0x7ffff7ffb000
  [ 8] .fake_shstrtab    STRTAB          0000000000000780 000780 000076 00   A  0   0 32

This is because sh_name==0 for the first section and .fake_shstrtab
errorneously did not contain 0x00 as its very first byte (as required by the
ELF standard) and therefore BFD considered the first section nameless.

I have verified the problem no longer occurs on:

kernel-3.17.0-0.rc7.git3.1.fc22.x86_64
(gdb) info files
0x00007ffff7ffd120 - 0x00007ffff7ffd160 is .hash in system-supplied DSO at 0x7ffff7ffd000
                                           ^^^^^
0x00007ffff7ffd160 - 0x00007ffff7ffd268 is .dynsym in system-supplied DSO at 0x7ffff7ffd000
0x00007ffff7ffd268 - 0x00007ffff7ffd2c6 is .dynstr in system-supplied DSO at 0x7ffff7ffd000
  [15] .shstrtab         STRTAB          0000000000000000 001308 0000a2 00      0   0  1

Expecting it is probably since:
	https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=da861e18ecccb5c126b9eb95ff720ce082a46286
	x86, vdso: Get rid of the fake section mechanism

I have tested that this older kernel also does not have the problem:
kernel-3.10.0-123.el7.x86_64
        0x00007ffff7ffa120 - 0x00007ffff7ffa160 is .hash in system-supplied DSO at 0x7ffff7ffa000
        0x00007ffff7ffa160 - 0x00007ffff7ffa268 is .dynsym in system-supplied DSO at 0x7ffff7ffa000
        0x00007ffff7ffa268 - 0x00007ffff7ffa2c6 is .dynstr in system-supplied DSO at 0x7ffff7ffa000
  [15] .shstrtab         STRTAB          0000000000000000 00105a 0000a3 00      0   0  1

Therefore I do not think it is worth workarounding in GDB.


Jan