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: Yao Qi <qiyaoltc at gmail dot com>
- To: Pedro Alves <palves at redhat dot com>, Taimoor <tmirza at codesourcery dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Thu, 11 Jun 2015 09:30:34 +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> <55784D18 dot 2000003 at redhat dot com>
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 (éå)