RFA: AIX 64-bit mega-patch
Sat Jun 10 18:58:00 GMT 2000
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
> A ``thread'' would be the usual execution object from a process or a core
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:
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.
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.
More information about the Gdb-patches