Re: Improving GDB's mechanism to check if function is GC'ed

[Luis Machado <lgustavo at codesourcery dot com>]

On 06/10/2015 05:53 AM, Yao Qi wrote:
> Taimoor <tmirza@codesourcery.com> writes:
>
> Hi Taimoor,
> I happen to have to some time today to read your patch, here are my
> comments below,
>
> > Current Problem
> > ===============
> >
> > We are currently using GDB to debug Nucleus based bare-metal system
> > that also allows to dynamically load and unload Nucleus process
> > modules during system execution.
> > We currently load symbols of a modules using add-symbol-file whenever
> > a module is loaded at runtime. It is very common to have functions at
> > address 0x0 in debug information and then lowpc in symbol table to be
> > non-zero as it depends on section addresses given in add-symbol-file
> > command.
>
> GDB just uses some heuristics to determine whether the function is GC'ed
> by linker, so they may not be perfect.  However, GDB doesn't support
> Nucleus, so it isn't a valid case to me.  Do we have other cases that we
> add-symbol-file in which function address is at 0x0 on platforms GDB
> supports?
>
> If the problem only exists on Nucleus, I am afraid I don't agree with
> accepting this change, because GDB doesn't support Nucleus.  Sorry.

add-symbol-file can cause things to get weird with addresses given the 
user can specify the base address as it pleases. I don't think this is 
Nucleus-specific at all, but more generally bare-metal-specific.

I take it DWARF says 0x0 and GDB relocates the symbol file/addresses 
based on the provided base address? Taimoor?