RE: Debugging MIPS PIE executables

[Felix Radensky <felix dot radensky at broadcom dot com>]

Hi Matthew,

> -----Original Message-----
> From: Matthew Fortune [mailto:Matthew.Fortune@imgtec.com]
> Sent: Tuesday, June 16, 2015 3:07 PM
> To: Felix Radensky; binutils@sourceware.org
> Subject: RE: Debugging MIPS PIE executables
> 
> Felix Radensky <felix.radensky@broadcom.com> writes:
> > > -----Original Message-----
> > > From: Matthew Fortune [mailto:Matthew.Fortune@imgtec.com]
> > > Sent: Monday, June 15, 2015 9:03 PM
> > > To: Felix Radensky; binutils@sourceware.org
> > > Subject: RE: Debugging MIPS PIE executables
> > >
> > > Felix Radensky <felix.radensky@broadcom.com> writes:
> > > > Hi Mattew
> > > >
> > > > > -----Original Message-----
> > > > > From: Matthew Fortune [mailto:Matthew.Fortune@imgtec.com]
> > > > > Sent: Saturday, June 13, 2015 11:10 AM
> > > > > To: Felix Radensky; binutils@sourceware.org
> > > > > Subject: RE: Debugging MIPS PIE executables
> > > > >
> > > > > Felix Radensky <felix.radensky@broadcom.com> writes:
> > > > > > Hi Matthew,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Matthew Fortune [mailto:Matthew.Fortune@imgtec.com]
> > > > > > > Sent: Sunday, June 07, 2015 11:10 AM
> > > > > > > To: Felix Radensky; binutils@sourceware.org
> > > > > > > Subject: RE: Debugging MIPS PIE executables
> > > > > > >
> > > > > > > Hi Felix,
> > > > > > >
> > > > > > > Felix Radensky <felix.radensky@broadcom.com> writes:
> > > > > > > > I was wondering if any progress was made to resolve the
> > > > > > > > problem discussed in the following threads:
> > > > > > > >
> > > > > > > > https://sourceware.org/ml/binutils/2013-06/msg00183.html
> > > > > > > > https://sourceware.org/ml/binutils/2014-10/msg00200.html
> > > > > > > >
> > > > > > > > Are there any experimental patches for binutils/gdb/glibc
> > > > > > > > that
> > > > I
> > > > > > can
> > > > > > > > try ? PIE executables are must in many security-conscious
> > > > > > > > projects, and the lack of ability to debug them is a
> > > > > > > > serious
> > > > problem.
> > > > > > >
> > > > > > > This request has come up a few times again recently and I am
> > > > > > > hoping
> > > > > > to
> > > > > > > submit patches for this in the coming week. I still have not
> > > > > > > managed to build a PIE version of glibc which is a bit of a
> > > > > > > blocker. I'm currently trying to use HJ's recent patches to
> > > > > > > support PIE by default from GCC but now have link assertions
> > > > > > > in glibc instead of reloc
> > > > > > failures.
> > > > > > >
> > > > > > > I have binutils and gdb patches that have been used with
> > > > > > > bionic but they still need some cleaning up.
> > > > > >
> > > > > > Thanks a lot for a prompt reply. I'm looking forward to test
> > > > > > your patches.
> > > > >
> > > > > I've attached the patches I intend to submit but I still have to
> > > > > work through the binutils testsuite to account for the new tag
> > > > > and try to
> > > > write a useful test case.
> > > > > I'll also need to get advice on doing a GDB test for this as I
> > > > > don't know if/how to do that.
> > > > >
> > > > > The patches are manually tested for o32/n32/n64 PIE and ordinary
> > > > > executables with the expected behaviour that new PIEs with new
> > > > > ld.so show the correct library list.
> > > > >
> > > >
> > > > I've build a MIPS o32 little-endian toolchain using crosstool-ng-
> > > > 1.21.0, with gcc-5.1.0, binutils-2.25 and gdb-7.9.1, and your
> > > > patches applied. However the problem still exists, I'm unable to
> > > > debug PIE executables with shared libraries or inspect core files
> > > > produced by such executables. The shared library is not listed by
> > > > "info sharedlibrary", the backtrace cannot be extracted from core
> > > > file. I can send you my crosstool-ng configuration file and the
> > > > trivial application I use for testing.
> > >
> > > The support in the GDB side of this depends on the elf.h header
> > > having the
> > > DT_MIPS_RLD_MAP2 macro defined. Are you using native GDB or remote
> > > with the gdbserver? The gdbserver does the work for finding shared
> > > library debug if you are using a remote so has to be built from the patched
> sources.
> > >
> > > Debugging tips would be to firstly check that your PIE has the
> > > DT_MIPS_RLD_MAP2 tag using readelf. To get a textual description of
> > > the tag you will have to use readelf built from the patched binutils source.
> > >
> > > Then double check that GDB has been built against headers that
> > > define DT_MIPS_RLD_MAP2, the GLIBC patch includes changes to add
> > > this to the headers.
> > >
> >
> > Thanks for the tips. I've verified that my PIE executable has
> > DT_MIPS_RLD_MAP2 tag. Also recompiled cross GDB, gdbserver and native
> > GDB with DT_MIPS_RLD_MAP2 defined. I can now successfully debug my PIE
> > executable using gdbserver and cross GDB. What I still cannot do is to debug
> using native GDB and to inspect core files using cross GDB.
> 
> Core files would be new territory for me so it will take a bit of exploring to
> understand what piece of the puzzle is missing. Presumably the core file carries
> some indication of where the r_debug map is and that is not getting set
> correctly when generating the core file.
> 
> I'll switch this over to the GDB list if I get stuck.
> 
> 

Actually core file inspection works fine for me with native GDB on the target, as well as debugging with native GDB. It's only the core file inspection in cross GDB that doesn't work.

Felix.