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

[Yao Qi <qiyaoltc at gmail dot com>]

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.

>
> Possible Solution
> =================
>
> * Modify GC checking mechanism to mark any function GC'ed using above
> mentioned mechanism only if objfile is not dynamically loaded. So, for
> any function with address 0x0, it'll be marked GC'ed only if lowpc is
> not zero and objfile is main symbol file.
>
> For this I have made following modifications in if condition:
>
> if (address == 0 && address < lowpc
>     && (objfile->flags & OBJF_MAINLINE))
>     {
>
> I have regression tested this change and it seems to work fine.
> Only downside that it is possible (though not common) to load main
> symbol file using add-symbol-file command. In that case, GDB will not
> check for GC'ed functions.

In this way, GDB doesn't ignore the GC'ed function from the dynamically
loaded objects, which is a regression to me.

-- 
Yao (éå)