This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: determining whether page 0 (or low addresses in general) is executable
On Wed, Apr 16, 2008 at 12:33 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Wed, Apr 16, 2008 at 12:20:47PM -0700, Doug Evans wrote:
> > Hi. We're trying to come up with a workaround for an apparent gcc/linker issue
> > where debug info can be left behind that messes up backtraces.
> > The erroneous debug info shouldn't be generated, but gdb could do a better
> > job when faced with it.
>
> Not much better; I would suggest effort be spent on the
> linker/compiler limitations, instead. For instance moving debug info
> into comdat sections.
Hopefully that'll get done too of course.
> I thought GNU ld only had this problem for .debug_info and already
> edited out discarded FDEs from .debug_frame / .eh_frame. Are you
> using GNU ld or gold? Maybe the linker only edits .eh_frame.
Actually the problem occurs with both gld and gold. The linker does
explicitly handle .eh_frame, and I'm told the debug info doesn't go
into comdat on purpose (complexity issues I gather).
>
>
> > *************** dwarf2_frame_find_fde (CORE_ADDR *pc)
> > @@ -1585,6 +1608,13 @@
> >
> > while (fde)
> > {
> > + if (fde->initial_location + offset == 0
> > + && !is_zero_page_executable ())
> > + {
> > + /* Ignore this FDE -- linker bug. */
> > + fde = fde->next;
> > + continue;
> > + }
> >
>
> See has_section_at_zero in dwarf2read.c. It's just the same hack.
Ah. Thanks.