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
next prev parent 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