Re: determining whether page 0 (or low addresses in general) is executable

["Doug Evans" <dje@google.com>]

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.