This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RFA: AIX 64-bit mega-patch


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]