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)".