Bug 223702 - --db-command should support %{auxv address}
Summary: --db-command should support %{auxv address}
Status: RESOLVED NOT A BUG
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-21 19:13 UTC by Jan Kratochvil
Modified: 2012-05-26 16:01 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kratochvil 2010-01-21 19:13:14 UTC
Version:           valgrind-3.5.0-9.x86_64 (using Devel)
OS:                Linux
Installed from:    Compiled sources

valgrind --db-attach pie-executable
does not currently work if /lib64/ld*.so is not prelinked.

FSF GDB support for PIE (Position Independent Executable; built using -fPIE -pie) debugging has been checked-in to CVS HEAD (->gdb-7.1):
http://sourceware.org/ml/gdb-patches/2010-01/msg00233.html

It currently works for all these cases (simplified):
gdb -p normal-executable
gdb -p pie-executable-prelinked
gdb -p pie-executable-unprelinked
valgrind --db-attach normal-executable
valgrind --db-attach pie-executable-prelinked-only-if-ld.so-is-prelinked
valgrind --db-attach pie-executable-unprelinked-only-if-ld.so-is-prelinked

It does not work for:
valgrind --db-attach pie-executable-prelinked-only-if-ld.so-is-unprelinked
valgrind --db-attach pie-executable-unprelinked-only-if-ld.so-is-unprelinked

GDB generally wants to know AUXV of the debugged process.  With AUXV and its AT_ENTRY value it can find the executable offset and relocate its symbols for it.

Normally /proc/PID/auxv is read to find the AUXV content.  But with valgrind it does not match, therefore for attachments it rather uses "_dl_auxv" (located in ld.so).  GDB cannot use backtrace from main to _start to find the valgrind-modified auxv there as the initial thread may have exited (+it would be too fragile anyway).

But to locate "_dl_auxv" we need relocated symbols for ld.so which is a chicked-and-egg problem.  DT_DEBUG
is in the main executable (which would point us at ld.so load address) but we need AUXV to find out how to relocate symbols for the PIE main executable.

Therefore we known neither the main executable offset (as it is PIE) and therefore neither DT_DEBUG and therefore neither ld.so offset (as it is PIC and not prelinked loaded at arbitrary address) and therefore neither "_dl_auxv" offset and /proc/PID/auxv is invalid with valgrind attachments.  There is everything floating.

Therefore suggesting to create besides %f and %p --db-command substitutions also some %a producing string "0x7fffffffd7e0" which would correspond to "the_iifii.client_auxv" (or where is the AUXV address stored).  GDB will get corresponding "--auxv" commandline option / CLI setting.  Thanks.
Comment 1 Philippe Waroquiers 2012-05-26 11:49:15 UTC
Since Valgrind 3.7.0, there is an embedded gdbserver, which returns the auxv
to GDB.
Is that working in your case ?
Comment 2 Jan Kratochvil 2012-05-26 13:14:30 UTC
Yes, it works, thanks:
0x00000030005087a9 in main () at pie.c:4
4	  *(int *)0=0;

BTW it would be nice to start GDB automatically, like with --db-attach=yes.
gdb ./pie -ex 'target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=11325'
Comment 3 Philippe Waroquiers 2012-05-26 15:32:32 UTC
(In reply to comment #2)
> Yes, it works, thanks:
> 0x00000030005087a9 in main () at pie.c:4
> 4	  *(int *)0=0;
> 
> BTW it would be nice to start GDB automatically, like with --db-attach=yes.
> gdb ./pie -ex 'target remote | /usr/lib64/valgrind/../../bin/vgdb
> --pid=11325'

We could implement --db-attach=vgdb to indicate that the gdbserver should be used to
"attach" (rather than the old --db-attach technique of forking the process, and have the parent launching a gdb to attach
to the forked process).

However, if the Valgrind process launches a gdb as suggested above, I am wondering
what will happen with stdin, C-c, ...  when continue is done in the gdb.
Comment 4 Tom Hughes 2012-05-26 15:43:20 UTC
We should just scrap the old db-attach technology I suspect...
Comment 5 Jan Kratochvil 2012-05-26 16:01:24 UTC
With "set target-async on" it should work
(resume->target_terminal_inferior->remote_terminal_inferior).
With "set target-async off" (the current default) it will probably not.
"set target-async on" should fortunately become the default in a reasonable time.