This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [7.0] PR/9723: gdb breakpoints silently fail on PIE binaries
> From: Thiago Jung Bauermann <thiago.bauermann@gmail.com>
> Date: Fri, 24 Jul 2009 23:12:41 -0300
>
> Em Segunda-feira 20 Julho 2009 01:13:00 Paul Pluzhnikov escreveu:
> > On Sun, Jul 19, 2009 at 6:57 PM, Thiago Jung
> >
> > Bauermann<thiago.bauermann@gmail.com> wrote:
> > > All this to say: can somebody save me some research time and tell in high
> > > level how can I recognize from looking at an ELF file that I'm dealing
> > > with a PIE binary (NOT a PIC library, of course)? Something like "see if
> > > the frob bit in the bozo section is set") is enough, I can go from there.
> >
> > Elf*_Ehdr.e_type == ET_DYN for the main executable?
> >
> > Elf*_Phdr.p_vaddr == 0 for the first PT_LOAD segment?
> > [This one is only true for non-prelinked -pie executable.]
>
> Great, thanks for the tip. Since nobody jumped into discussion, I assume any
> of those ways will work and have no known side-effect or false
> positive/negative. We'll see. :-)
Well, I'm not sure the second method is something you can rely on. I
think Elf*_Phdr.p_vaddr can be 0 for non-PIC executables as well on
some architectures.
> Now I have this issue, I'd like to ask people's opinion about it: by
> design (or defect?) the BFD library is a PITA to access the program
> header. I feel very tempted to use elf32.h and elf64.h directly in
> order to check that field. My only worry is that a cross-debugging
> session with a win32 gdb and a linux remote target would not be
> possible, unless windows includes such sysv elf headers too (perhaps
> it does?).
>
> Do you have an opinion?
Which elf32.h and elf64.h. I don't think those are standardized
headers in any way. Defenitely no files with those names under
/usr/include on OpenBSD. Heck, even my Linux workstation at work
doesn't have any files named like that.
There is "elf/common.h" in the src tree though.
Anyway, if the BFD library doesn't provide some functionality you
need, I think the best thing to do would be to add it there. There
seems to be an Elf_Internal_Phdr pointer in struct elf_obj_tdata, so
perhaps the only thing you need to add is a macro like elf_elfheader()
to access it.