This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [commit] Don't call deprecated_inside_entry_file from ...id_unwind()
- From: Andrew Cagney <cagney at gnu dot org>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 31 Oct 2003 21:02:04 -0500
- Subject: Re: [commit] Don't call deprecated_inside_entry_file from ...id_unwind()
- References: <3FA2F789.5000306@redhat.com> <20031101004443.GB11987@nevyn.them.org>
Are you certain that none of those other architectures needed the hack
anyway?
To sound like a scratched record, until there is hard evidence that this
test is needed it should _not_ be enabled. So far the only evidence is
that it is anything but needed:
/* NOTE: vinschen/2003-04-01: Disabled. It turns out that the call
to deprecated_inside_entry_file destroys a meaningful backtrace
under some conditions. E. g. the backtrace tests in the
asm-source testcase are broken for some targets. In this test
the functions are all implemented as part of one file and the
testcase is not necessarily linked with a start file (depending
on the target). What happens is, that the first frame is printed
normaly and following frames are treated as being inside the
enttry file then. This way, only the #0 frame is printed in the
backtrace output. */
Also, as I noted:
> That innocent looking code as quitely spread to at least 4 other
> architectures (there was no comment saying "hey you don't need this").
the mere presence of that code in those up-to-date targets was a great
big foobar.
Also, snce GDB does support backtracing when main isn't even in the
equation, I don't think we should break that unless the check is
actually harmful.
The only testcase that comes close to having a problem is asm-source and
that breaks with the test present.
You'll note that I've not touched legacy targets.
Andrew