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 06/10/2015 01:06 PM, Yao Qi wrote:
> On 10/06/15 11:17, Pedro Alves wrote:
>> Hmm, does it really need to, though?  We expose mechanisms like
>> add-symbol-file, xml library list with qXfer:libraries:read (the default
>> solib provider), xml target descriptions, "info os", etc., exactly so
>> that GDB doesn't have to learn about the myriad of random RTOS's out there.
> 
> If these stuffs (add-symbol-file, xml library list, etc) works well for
> the given RTOS, and GDB doesn't need to know about the RTOS, that is
> fine.  However, in this case, Nucleus needs some changes in GDB c code
> while GDB doesn't support Nucleus.  I can't see how this patch benefits
> any targets GDB supported.  This is the reason I think this patch is
> not acceptable.

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?

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.

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.

I'd suspect that things are broken too when targets list relocatable objects
in the qXfer:libraries:read list (in which case the target will list "section"
elements instead of "segment" elements for each "library" element), and that's
definitely meant to work.  ("If the target supports dynamic linking of a
relocatable object file, its library XML element should instead include
a list of allocated sections.")

Thanks,
Pedro Alves


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