This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: ping: [patch 1/6] PIE: Attach binary even after re-prelinked underneath
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 5 Jul 2010 19:22:30 +0200
- Subject: Re: ping: [patch 1/6] PIE: Attach binary even after re-prelinked underneath
- References: <20100329153031.GA31671@host0.dyn.jankratochvil.net> <20100609150753.GA7183@host0.dyn.jankratochvil.net> <20100629174216.GR2595@adacore.com> <20100704101635.GA6875@host0.dyn.jankratochvil.net> <20100705170602.GY2595@adacore.com>
On Mon, 05 Jul 2010 19:06:02 +0200, Joel Brobecker wrote:
> > gdb/
> > 2010-07-02 Jan Kratochvil <jan.kratochvil@redhat.com>
> > Joel Brobecker <brobecker@adacore.com>
> >
> > Fix attaching to PIEs prelinked on the disk after the process was
> > started.
> > * solib-svr4.c (svr4_exec_displacement): New variable arch_size.
> > Verify it against bfd_get_arch_size. Try to match arbitrary
> > displacement for the phdrs comparison.
> >
> > gdb/testsuite/
> > 2010-07-02 Jan Kratochvil <jan.kratochvil@redhat.com>
> > Joel Brobecker <brobecker@adacore.com>
> >
> > * gdb.base/break-interp.exp: Run $binpie with new value "ATTACH", new
> > code for it. New variable relink_args.
> > (prelinkYES): Call prelinkNO.
> > (test_attach): Accept new parameter relink_args. Re-prelink the binary
> > in such case. Move the core code to ...
> > (test_attach_gdb): ... a new function. Send GDB command "file".
> > Extend expected "Attaching to " string.
>
> This is OK, with one English error in one of my suggestions (mea culpa).
The "easier" -> "more easily" one? My fault, I forgot to include this fix by
you, sorry.
> > + /* PT_GNU_STACK is an exception by being never relocated by
> > + prelink as its addresses are always zero. */
>
> I understand why you mean, now, about the PT_GNU_STACK entry not being
> changed during the prelink. But I don't get the relationship between
> this comment and the code surrounding it. Can you explain that?
Code simplified for better readability in this mail:
/* PT_GNU_STACK is an exception by being never relocated by
prelink as its addresses are always zero. */
if (memcmp (phdrp, phdr2p, sizeof (*phdrp)) == 0)
continue;
/* Check also other adjustment combinations - PR 11786. */
*buf_vaddr_p -= displacement;
*buf_paddr_p -= displacement;
if (memcmp (phdrp, phdr2p, sizeof (*phdrp)) == 0)
continue;
For detected DISPLACEMENT value 0x3000000000 the latter test works:
PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x0001c0 0x0001c0 R E 0x8
->
PHDR 0x000040 0x0000003000000040 0x0000003000000040 0x0001c0 0x0001c0 R E 0x8
as 0x0000003000000040 - 0x3000000000 == 0x0000000000000040.
But in the same executable there is also
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8
->
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x8
but 0x0000000000000000 - 0x3000000000 == 0xffffffd000000000 and thus
0x0000000000000000 - 0x3000000000 != 0x0000000000000000
and we would fail the verification despite the executable perfectly matches.
I believe one should be looking at some two `readelf -Wa' dumps of an
executable with two prelink addresses while checking this code so it should be
apparent during real updates of that code.
Thanks,
Jan