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

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.

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.

> *************** 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.

-- 
Daniel Jacobowitz
CodeSourcery

On Wed, Apr 16, 2008 at 12:33 PM, Daniel Jacobowitz
<drowfalse.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.

On Wed, Apr 16, 2008 at 06:02:24PM -0700, Doug Evans wrote:
> >  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).

OK, so we could probably fix this in GNU ld by reusing the
eh-frame
editor for .debug_frame too.  COMDAT is better, of course. 
It's just
hard :-(

-- 
Daniel Jacobowitz
CodeSourcery