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

Yao Qi
2015-06-11T08:30:46Z

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 (é½å°§)