From 3cd07d204baadc4b3d148a7494366fc92e7d42b1 Mon Sep 17 00:00:00 2001 From: Jan Kratochvil Date: Mon, 5 Jul 2010 17:58:56 +0000 Subject: gdb/ * auxv.c (ld_so_xfer_auxv): Do not error on failed read of data_address. --- gdb/auxv.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) (limited to 'gdb/auxv.c') diff --git a/gdb/auxv.c b/gdb/auxv.c index ae9142a..4fc5c9c 100644 --- a/gdb/auxv.c +++ b/gdb/auxv.c @@ -96,7 +96,27 @@ ld_so_xfer_auxv (gdb_byte *readbuf, pointer_address = SYMBOL_VALUE_ADDRESS (msym); - data_address = read_memory_typed_address (pointer_address, ptr_type); + /* The location of the _dl_auxv symbol may no longer be correct if + ld.so runs at a different address than the one present in the file. + This is very common case - for unprelinked ld.so or with a PIE executable. + PIE executable forces random address even for libraries already being + prelinked to some address. PIE executables themselves are never prelinked + even on prelinked systems. Prelinking of a PIE executable would block + their purpose of randomizing load of everything including the executable. + + If the memory read fails, return -1 to fallback on another mechanism for + retrieving the AUXV. + + In most cases of a PIE running under valgrind there is no way to find + out the base addresses of any of ld.so, executable or AUXV as everything + is randomized and /proc information is not relevant for the virtual + executable running under valgrind. We think that we might need a valgrind + extension to make it work. This is PR 11440. */ + + if (target_read_memory (pointer_address, ptr_buf, ptr_size) != 0) + return -1; + + data_address = extract_typed_address (ptr_buf, ptr_type); /* Possibly still not initialized such as during an inferior startup. */ if (data_address == 0) -- cgit v1.1