This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: NPC_REGNUM, multi-arch and gdbserver
- To: shebs at apple dot com
- Subject: Re: NPC_REGNUM, multi-arch and gdbserver
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 02 May 2000 14:27:31 +1000
- CC: GDB Patches <gdb-patches at sourceware dot cygnus dot com>
- Organization: Cygnus Solutions
- References: <390AD87E.231EA249@cygnus.com> <390B3517.C533B816@apple.com>
Stan Shebs wrote:
>
> Andrew Cagney wrote:
> >
> > the underlying problem/question is how should gdbserver be built when
> > the upper-level GDB is being built multi-arch?
> >
> > Comments, ideas?
>
> I've thought about this from time to time...
>
> So the basic theory of gdbserver is that it's a stub for native
> systems, which means that it consists of a) a target-side remote
> protocol implementation, and b) a blob of native-only code to
> implement the remote protocol packets. Ideally, the blob of
> native code is the same as is used in full GDB, but in practice
> we replicate and strip down right now.
>
> The crux of the problem is that the lowest levels of native
> support may still need to know something about the target
> architecture, such as the number and size of registers, even
> though gdbserver doesn't have to care about stack frame layout
> or any other of the higher-level ABI knowledge.
>
> One possibility would be to have two architecture objects,
> a "higher level" one and a "lower level" one, or, as we've talked
> some about in the past, an "ABI" object that is different from
> a "raw arch" object, and then use the lower-level one in gdbserver.
> This is a bit much to bite off right now perhaps.
Er, yes. Lets first figure out a cannonical list of architecture methods
(high or low) :-).
> Another possibility would be to bolt the whole multi-arch framework
> into gdbserver. Although gdbserver should be small, it is intended
> to run on host systems, and so it doesn't have the stringent constraints
> of the usual embedded target.
I poked at that (linking gdbserver against libgdb.a) and it pulled in
all of GDB.
At present GDB is very undiciplined (it needs a good marching up and
down in the desert (sp?)) with random and arbitrary references.
> Finally, we could just say that gdbserver doesn't need to share
> anything with main GDB sources, and just kludge everything. This
> has the virtue of simplicity; we're not doubling the size of our
> source base for the sake of two macros.
I have a feeling this is the most pratical short term solution :-( It
means that either a separate copy of those needed macros is created, or
GDB be used to dump out the relevant macro's for gdbserver (ulgh).
Things like sparc32/64 would probably need two executables.
> Personally, I lean towards having the option of including multi-arch
> in gdbserver, mostly because in the long run I think we should make
> gdb and gdbserver use the same code as much as possible, and native
> support will in general need to access information about the target
> architecture. Using multi-arch means that gdbserver is more likely
> to "just work" and need less individual maintenance.
For it to ``just work'' I think we first need to get GDB into ship-shape
with respect to the basic gdbarch. Then we can re-arange things so that
there is a separation of the ISA/ABI. With that, making use of it by
gdbserver may be possible.
Looking down the track, there are two potential common area's between
GDB and GDBSERVER:
o the [Gg] packet layout.
I think this external interface should be
defined in, say src/include/gdb/???.h.
o the mechanism used to read/write
individual registers
beyond that I'm not sure how much commonality there will really be.
I'll see what tricks I can come up with for gdbarch in the non-
multi-arch case to keep it going.
Andrew