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

[Yao Qi <qiyaoltc@gmail.com>]

On 10/06/15 15:43, Pedro Alves wrote:
> This strikes me as an odd position, given the whole point of those commands
> and features is letting GDB support the target without builtin knowledge of
> them, so it's natural that GDB didn't have built-in support for the target
> thus far.  But now we broke one of the mechanisms for some use case.
> Put another way, if we added support for --target=$cpu-nucleus, just as a
> configure alias for --target=$cpu-elf, so that we could say we supported
> Nucleus, how would we go about fixing this?

Even Nucleus is supported in GDB, I don't know how to fix this problem
either.  If this problem only exist on Nucleus, do we need to fix this
problem?

>
> I think we need to look and understand_why_  Nucleous' binaries trigger
> the problem.  If they're standard elf, it just looks to me that Nucleous
> is a red herring.

I agree that we need look deep and understand why Nucleus binaries
trigger this problem, to see whether it is Nucleus specific or not.

>
> IIUC, this triggers on use of add-symbol-file with relocatable
> objects, when there's real code at address 0.  I think that's the angle
> we should look at things.
>

Yes, that is the problem.  GDB thinks the function is GC'ed by linker
but in fact it isn't.

-- 
Yao (齐尧)