This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: properly handle extensions to DWARF 2 line number information
- To: ac131313 at cygnus dot com
- Subject: Re: properly handle extensions to DWARF 2 line number information
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: Sun, 11 Nov 2001 13:36:27 -0800
- Cc: gdb-patches at sources dot redhat dot com, binutils at sources dot redhat dot com
- References: <200111111226.fABCQMv05908@thief.cygnus.com> <3BEEA2C0.30203@cygnus.com>
- Reply-to: Geoff Keating <geoffk at redhat dot com>
> Date: Sun, 11 Nov 2001 11:09:36 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020
> X-Accept-Language: en-us
> Cc: gdb-patches@sources.redhat.com, binutils@sources.redhat.com
>
> Er, probably not 5.1. People would probably like to see it working in
> the field first.
I see I have caught the GDB release process at a bad time. No
problem, it can wait for 5.1.1 or whatever.
Is it OK for the mainline?
The reason this came up was the following question:
> On a related matter, is there anything in an executable indicating
> which architecture an i386 binary belongs? Having a requrement that
> an (embedded) user explicitly set their architecture is pretty lame.
> The MIPS, for instance, detects and auto-selects both GDB and, if
> used, the simulator, based on information found in the executable.
The obvious way to do this is to generate and use the DWARF 3
line-number information, but while I was testing a patch to generate
it in GAS, I found that old GDB versions didn't ignore it as they
should; the effect is that a GAS that generates this produces objects
that can't usefully be debugged with a GDB without this patch.
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>