From: Pedro Alves <palves@redhat.com>
To: Yao Qi <qiyaoltc@gmail.com>, Taimoor <tmirza@codesourcery.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: Improving GDB's mechanism to check if function is GC'ed
Date: Wed, 10 Jun 2015 14:43:00 -0000 [thread overview]
Message-ID: <55784D18.2000003@redhat.com> (raw)
In-Reply-To: <5578285D.2030808@gmail.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
next prev parent reply other threads:[~2015-06-10 14:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-02 13:38 Taimoor
2015-06-09 6:16 ` Taimoor
2015-06-09 13:36 ` Yao Qi
2015-06-10 8:54 ` Yao Qi
2015-06-10 10:17 ` Pedro Alves
2015-06-10 12:04 ` Taimoor
2015-06-10 12:07 ` Yao Qi
2015-06-10 14:43 ` Pedro Alves [this message]
2015-06-11 8:30 ` Yao Qi
2015-06-11 8:54 ` Pedro Alves
2015-06-10 11:18 ` Luis Machado
2015-06-10 11:46 ` Taimoor
2015-06-10 12:25 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55784D18.2000003@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=qiyaoltc@gmail.com \
--cc=tmirza@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox