gdb/gdb-prelink-rela.patch
Jan Kratochvil 833b1257d3 - Rebase to FSF GDB 7.2.50.20110222 (which is a 7.3 pre-release).
- Fix attach/core-load of {,un}prelinked i386 libs (bugreport by Michal Toman).
2011-02-23 00:35:53 +01:00

142 lines
5.6 KiB
Diff

http://sourceware.org/ml/gdb-patches/2011-02/msg00630.html
Subject: [patch] [i386] Fix {,un}prelinked libraries for attach/core-load
Hi,
please see comments in the patch. The adjusted testcase FAILs on i386.
"Prelink", March 4, 2004 - by Jakub Jelinek:
http://people.redhat.com/jakub/prelink.pdf
primarily section 7 - REL to RELA conversion
An example of unprelinked -> prelinked library change:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
- LOAD 0x000000 0x00000000 0x00000000 0x00538 0x00538 R E 0x1000
- LOAD 0x000538 0x00001538 0x00001538 0x00100 0x00110 RW 0x1000
- DYNAMIC 0x000550 0x00001550 0x00001550 0x000c8 0x000c8 RW 0x4
- NOTE 0x0000f4 0x000000f4 0x000000f4 0x00024 0x00024 R 0x4
- GNU_EH_FRAME 0x0004e8 0x000004e8 0x000004e8 0x00014 0x00014 R 0x4
+ LOAD 0x000000 0x411b3000 0x411b3000 0x00558 0x00558 R E 0x1000
+ LOAD 0x000558 0x411b4558 0x411b4558 0x00100 0x00110 RW 0x1000
+ DYNAMIC 0x000570 0x411b4570 0x411b4570 0x000c8 0x000c8 RW 0x4
+ NOTE 0x0000f4 0x411b30f4 0x411b30f4 0x00024 0x00024 R 0x4
+ GNU_EH_FRAME 0x000508 0x411b3508 0x411b3508 0x00014 0x00014 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
So far GDB expected all such displacements will be always PAGE_SIZE aligned.
This applies for example for re-prelinking of an already prelinked file.
But it does not apply for prelinking of an unprelinked file or unprelinking of
a prelinked file, there can be arbitrary displacement.
It affects i386 (=i686, prelink doc reports also ARM and MIPS) which uses REL.
x86_64 always uses RELA, therefore I have not noticed it so far. i386 still
has to be supported.
This affects both attachment to a PID and core file loads.
This applies in real world if you transfer a core file between hosts and try to
backtrace them, libraries of both hosts may differ whether they are / are not
prelinked.
I could implement some (displacement-forgiving and prelink-modifications
forgiving) comparison of both DYNAMIC segments found. But I do not think it is
useful, if the DYNAMIC address from linkmap vs. bfd do not match it is still a
better chance to try a displacement to make them match. Keeping the file
relocation cannot work anyway when the DYNAMIC address is verified as wrong.
No regressions on {x86_64,x86_64-m32,i686}-fedora15-linux-gnu.
Mostly do you agree the DYNAMIC content does not have to be verifed?
Do you have any comments on the in-code long comments?
Thanks,
Jan
gdb/
2011-02-22 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix libraries displacement if they change whether they were prelinked.
* solib-svr4.c (LM_ADDR_CHECK): Set L_ADDR even if the DYNAMIC pointer
does not match. Comment why.
gdb/testsuite/
2011-02-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/break-interp-lib.c (v, vptr): New variables.
* gdb.base/break-interp.exp (test_attach): New comment.
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -237,11 +237,11 @@ LM_ADDR_CHECK (struct so_list *so, bfd *abfd)
Even on PPC it must be zero-aligned at least for MINPAGESIZE. */
+ l_addr = l_dynaddr - dynaddr;
+
if ((l_addr & (minpagesize - 1)) == 0
&& (l_addr & align) == ((l_dynaddr - dynaddr) & align))
{
- l_addr = l_dynaddr - dynaddr;
-
if (info_verbose)
printf_unfiltered (_("Using PIC (Position Independent Code) "
"prelink displacement %s for \"%s\".\n"),
@@ -249,9 +249,20 @@ LM_ADDR_CHECK (struct so_list *so, bfd *abfd)
so->so_name);
}
else
- warning (_(".dynamic section for \"%s\" "
- "is not at the expected address "
- "(wrong library or version mismatch?)"), so->so_name);
+ {
+ /* There is no way to verify the library file matches. prelink
+ can during prelinking of an unprelinked file (or unprelinking
+ of a prelinked file) shift the DYNAMIC segment by arbitrary
+ offset without any page size alignment. There is no way to
+ find out the ELF header and/or Program Headers for a limited
+ verification if it they match. One could do a verification
+ of the DYNAMIC segment. Still the found address is the best
+ one GDB could find. */
+
+ warning (_(".dynamic section for \"%s\" "
+ "is not at the expected address "
+ "(wrong library or version mismatch?)"), so->so_name);
+ }
}
set_addr:
--- a/gdb/testsuite/gdb.base/break-interp-lib.c
+++ b/gdb/testsuite/gdb.base/break-interp-lib.c
@@ -20,6 +20,10 @@
#include <assert.h>
#include <stdio.h>
+/* Force REL->RELA conversion on i386, see "Prelink", March 4, 2004. */
+volatile int v[2];
+volatile int *vptr = &v[1];
+
void
libfunc (const char *action)
{
--- a/gdb/testsuite/gdb.base/break-interp.exp
+++ b/gdb/testsuite/gdb.base/break-interp.exp
@@ -352,6 +352,14 @@ proc test_attach {file displacement {relink_args ""}} {
# test simplicity, we merged this test and the test above by not
# restoring $INTERP after $EXEC prelink. $INTERP gets restored
# later below.
+ #
+ # `(wrong library or version mismatch?)' messages are printed for
+ # $binfile_lib on platforms converting REL->RELA relocations by
+ # prelink (such as on i386). There is no reliable way to verify
+ # the library file matches the running library in such case but
+ # GDB at least attempts to set the right displacement. We test
+ # `libfunc' is present in the backtrace and therefore the
+ # displacement has been guessed right.
if [prelink$relink $relink_args [file tail $exec]] {
# /proc/PID/exe cannot be loaded as it is "EXECNAME (deleted)".