This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]