symtab/2472: Dwarf problem with functions close to address 0x0 if linker gc in use

[jifl at ecoscentric dot com]

>Number:         2472
>Category:       symtab
>Synopsis:       Dwarf problem with functions close to address 0x0 if linker gc in use
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 27 18:48:02 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     jifl@ecoscentric.com
>Release:        gdb-6.8
>Organization:
>Environment:

>Description:
As described here:
http://sourceware.org/ml/gdb-patches/2008-06/msg00497.html
linker garbage collection removes functions, but can leave behind the DWARF2 frame info. The frames end up marked with location 0. Normally GDB gets away with this, but not if there are genuine functions close to 0. If that happens dwarf2_frame_find_fde can get a bad match on the wrong function.

The patch in the associated mail http://sourceware.org/ml/gdb-patches/2008-06/msg00498.html also contained a suggested fix. But as per http://sourceware.org/ml/gdb-patches/2008-06/msg00503.html there could be a problem if there are functions that really do start at address 0x0.

The suggestion is to "Take a look at the debug_info reader to see how we handled this case for symbolic debug info." which is beyond the scope of what I can manage without taking a while to get up to speed with the intricacies of the dwarf2 reader, so hopefully this bug submission will ensure the issue is not lost.
>How-To-Repeat:
I have not been able to find a way to demonstrate this in a target-independent way. Even a hacked around native linux linker script (producing executables that could never run) will stick main off at 0x1a3 - quite a bit from 0.

I was originally able to reproduce it with an in-house port to an embedded board.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: