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

Jan Kratochvil
2014-10-05T16:43:55Z

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