This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Improving GDB's mechanism to check if function is GC'ed
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>, Taimoor <tmirza at codesourcery dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 10 Jun 2015 15:43:36 +0100
- Subject: Re: Improving GDB's mechanism to check if function is GC'ed
- Authentication-results: sourceware.org; auth=none
- References: <556DB1BB dot 50601 at codesourcery dot com> <86eglkeyfw dot fsf at gmail dot com> <55780EB4 dot 1070003 at redhat dot com> <5578285D dot 2030808 at gmail dot com>
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