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: Re: RFC: Verify AT_ENTRY before using it
Date: Thu, 25 Feb 2010 22:16:00 -0000	[thread overview]
Message-ID: <20100225221620.GA7830@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <20100224224913.GA25437@caradoc.them.org>

On Wed, 24 Feb 2010 23:49:19 +0100, Daniel Jacobowitz wrote:
> In one window, "gdbserver :PORT /path/to/this/loader /path/to/binary".
> In the other, "gdb /path/to/binary" and "target remote :PORT".

In such case the symbol file ("/path/to/binary") does not correspond to the
target memory ("/path/to/this/loader").  In real world it works and
I understand my PIE patch has brought in a regression.


I would find more correct to use "gdb /path/to/this/loader" instead.  This
would be mostly equivalent to local:
	./gdb -nx -ex 'set breakpoint pending on' -ex 'b main' -ex r --args /lib64/ld-linux-x86-64.so.2 ./gdb -nx
which currently does not work, though.  GDB does not find out it should load
"./gdb" after ld.so loads the "./gdb" binary.

It is because _r_debug->r_map[0].l_name is forced to be "" by ld.so instead of
the real executable name.

The real executable name can be found from _dl_argv[0]; -> a different patch.


> Starting with the merge of PIE support, this blows up.  GDB tries to
> relocate BINARY by the auxv AT_ENTRY value, but AT_ENTRY describes the
> loader, not the binary.

This has been address by this pending patch ...
	Re: [patch] Sanity check PIE displacement #2
	http://sourceware.org/ml/gdb-patches/2010-02/msg00346.html


> I chose to fix this by a program header comparison.

... although I understand the patch of yours is more reliable than just the
displacement page size alignment.


> Any comments, or shall I commit this?

I agree with the patch, I will rebase the "displacement #2" on top of it with
some additional one to make "gdb /path/to/this/loader" working.


> +static gdb_byte *
> +bfd_read_program_headers (bfd *abfd, int *phdrs_size)

(besides missing comment)
/* Return newly allocated memory with ELF program headers content.  Store the
   allocated size in *PHDRS_SIZE, PHDRS_SIZE must not be NULL.  */

Should GDB ever use symbols starting "bfd_*"?  They may clash with bfd/ files.


> +{
> +  Elf_Internal_Ehdr *ehdr;
> +  gdb_byte *buf;
> +
> +  ehdr = elf_elfheader (abfd);

I miss here
  if (bfd_get_flavour (abfd) != bfd_target_elf_flavour)
    return NULL;


> +      int phdrs_size, phdrs2_size, ok = 0;
...
> +      buf = read_program_header (-1, &phdrs_size, NULL);
> +      buf2 = bfd_read_program_headers (exec_bfd, &phdrs2_size);
> +      if (buf != NULL && buf2 != NULL
> +	  && phdrs_size == phdrs2_size
> +	  && memcmp (buf, buf2, phdrs_size) == 0)
> +	ok = 1;
> +      xfree (buf);
> +      xfree (buf2);
> +
> +      if (ok)
> +	return entry_point - bfd_get_start_address (exec_bfd);
> +    }
>  
>    return svr4_static_exec_displacement ();

If the comparison cannot be made (such as on non-ELF files - are they really
sometimes used with solib-svr4.c?) the code is pessimistic and rather does NOT
use the PIE displacement.  Just a statement, unaware of non-PIE targets.


Thanks,
Jan


  reply	other threads:[~2010-02-25 22:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-24 22:49 Daniel Jacobowitz
2010-02-25 22:16 ` Jan Kratochvil [this message]
2010-02-26 21:12   ` Daniel Jacobowitz
2010-03-01 20:04     ` Jan Kratochvil
2010-03-01 21:22       ` [patch-testcase] " Jan Kratochvil
2010-03-08 22:13         ` Daniel Jacobowitz
2010-03-11 21:54           ` Jan Kratochvil
2010-03-11 21:57             ` Daniel Jacobowitz
2010-03-11 22:07               ` Jan Kratochvil
2010-03-08 22:06       ` Daniel Jacobowitz
2010-03-10 21:11         ` Jan Kratochvil
2010-03-10 21:55           ` Daniel Jacobowitz
2010-03-12 15:28           ` Jan Kratochvil
2010-03-12 15:39             ` Daniel Jacobowitz
2010-03-14  9:00               ` 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=20100225221620.GA7830@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