Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: gdb-patches@sourceware.org
Subject: [patch 2/6] PIE: Attach binary even after ld.so re-prelinked  underneath
Date: Mon, 29 Mar 2010 16:17:00 -0000	[thread overview]
Message-ID: <20100329161657.GA2940@host0.dyn.jankratochvil.net> (raw)

Hi,

when I have seen the PIE-binary-changed-sice-start tested also
ld.so-changed-since-start and it did not work.

There is questionable when to print and when to not to print non-fatal memory
read errors.  Similar change I requested in
	Re: [RFC/ia64] memory error when reading wrong core file
	http://sourceware.org/ml/gdb-patches/2010-02/msg00001.html
so that GDB prints at least as a warning
	Cannot access memory at address ...
when some unexpected error happens.

Contrary to it there is not such warning present in the code below as in the
case of non-valgrind PIE with re-prelinked ld.so the memory read error happens
there.  Some GDB code rework could probably avoid it.

Just for example all the memory read errors in read_program_header or even
- primarily - scan_dyntag are currently IMO-incorrectly silent and others.
Therefore posted the patch this way, making all these warnings printed and
possibly fixing code attempting incorrect reads along the way could be done by
a different patch.

No regressions on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu for the whole
patch series together.


Thanks,
Jan


gdb/
2010-03-29  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* auxv.c (ld_so_xfer_auxv): Do not error on failed read of data_address.

gdb/testsuite/
2010-03-29  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* gdb.base/break-interp.exp (test_attach): Keep $interp changed.  Move
	its restore after the <$relink_args != ""> loop.  new comment.

--- a/gdb/auxv.c
+++ b/gdb/auxv.c
@@ -96,7 +96,16 @@ ld_so_xfer_auxv (gdb_byte *readbuf,
 
   pointer_address = SYMBOL_VALUE_ADDRESS (msym);
 
-  data_address = read_memory_typed_address (pointer_address, ptr_type);
+  /* While it is an error I am not aware how to solve attaching to PIE under
+     valgrind --db-attach=yes different way when ld.so on-disk file has prelink
+     change in the meantime.  Currently GDB will drop back to procfs_xfer_auxv
+     (so that at least non-valgrind PIE attachments with prelink change of
+     ld.so work).  To make it working even with valgrind is PR 11440 requiring
+     a valgrind extension.  */
+  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)
--- a/gdb/testsuite/gdb.base/break-interp.exp
+++ b/gdb/testsuite/gdb.base/break-interp.exp
@@ -419,12 +419,16 @@ proc test_attach {file displacement {relink_args ""}} {
 	global exec interp_saved interp
 
 	foreach relink {YES NO} {
-	    if {[prelink$relink $relink_args [file tail $exec]]
-	        && [copy $interp_saved $interp]} {
+	    # It would be more correct to also [copy $interp_saved $interp]
+	    # here to really test just different prelink of $exec.
+	    # But we would need a separate test for different prelink of ld.so
+	    # where a bug occured.  It is now all merged into this single test.
+	    if [prelink$relink $relink_args [file tail $exec]] {
 		# /proc/PID/exe cannot be loaded as it is "EXECNAME (deleted)".
 		test_attach_gdb $exec $pid $displacement "attach-relink$relink"
 	    }
 	}
+	copy $interp_saved $interp
     }
 
     remote_exec host "kill -9 $pid"


             reply	other threads:[~2010-03-29 16:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-29 16:17 Jan Kratochvil [this message]
2010-06-09 15:08 ` ping: " Jan Kratochvil
2010-06-29 18:21   ` Joel Brobecker
2010-07-04 10:17     ` Jan Kratochvil
2010-07-05 17:15       ` Joel Brobecker
2010-07-05 18:10         ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100329161657.GA2940@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox