This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Verify AT_ENTRY before using it


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]