This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: RFA: AIX 64-bit mega-patch
- To: Nick Duffek <nsd at redhat dot com>
- Subject: Re: RFA: AIX 64-bit mega-patch
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Sun, 11 Jun 2000 11:56:54 +1000
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <3940556F.EED024FE@cygnus.com> <200006091906.PAA18553@nog.bosbc.com>
Nick Duffek wrote:
>
> On 9-Jun-2000, Andrew Cagney wrote:
>
> >Drop a tag before the commit.
>
> Thanks for the suggestion, I'll do that.
>
> >It may be possible to carve up this patch and get some of it in
> >immediatly. I guess, wait and see.
>
> I took a stab at cutting it into parts, but it's very interdependent. The
> binutils folks were responsive the last time I submitted patches, so I'm
> hopeful that it won't be long.
>
> >The theory is that, eventully, an architecture will be bound to each
> >``thread''.
>
> A ``thread'' would be the usual execution object from a process or a core
> file?
Yes, the thing with registers, address space, isa, abi, ...
> On the topic of multi-arch debugging, I've been wondering about a couple
> of other things:
>
> 1. When there's no process and no core file, should the architecture
> be inferred from the current target machine instead of from the
> object file? This would avoid the potential confusion of multiple
> assembly formats or even languages, e.g.:
>
> $ gdb foo
> (gdb) disassemble main
> ... assembly language 1 ...
> (gdb) break main
> (gdb) run
> (gdb) disassemble main
> ... assembly language 2 ...
Whats happening now? I would expect the action:
(gdb) file foo
to set everything up for foo so that a later:
(gdb) run
didn't change things - the architecture hadn't changed.
> 2. Should the "set architecture" command be sticky? If someone uses
> that command, they're probably dissatisfied with GDB's architecture
> inference, so they might not want GDB re-inferring the architecture
> every time they start a new inferior or load a new core file.
It is sticky - well as sticky as it can be in the circumstances. The
problem is gdbarch is really two objects - the ISA and the ABI (and
knowing my luck a few others :-). ``set architecture'' sets just the
ISA. Even with the ISA hard wired, the ABI could change. A separate
``set abi'' or ``set architecture <isa> <abi>'' will likely be needed.
``set abi'' is nasty, it is a context sensative (isa dependant) command.
Some history:
When gdbarch was first sketched out it was acknowledged that there was
the possability that this monolythic architecture object could really be
a number of separate objects. It was thought, however, that things
would be more managable if first a single monolythic architecture object
was created and then, later, options such as breaking that architecture
down were investiagated. A big part of the the rationale that lead to
the decisioin was that GDB internally does not clearly differentiate
between any of ISA, ABI or TARGET - the strategy is to first get an
object and then, later, clean it up.
In hindsite it was actually a good decision.
Andrew