This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Verify AT_ENTRY before using it
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: gdb-patches at sourceware dot org
- Date: Thu, 25 Feb 2010 23:16:20 +0100
- Subject: Re: RFC: Verify AT_ENTRY before using it
- References: <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