How does one cross-compile gdbserver?

How does one cross-compile gdbserver?

[Dan Kegel]

I'm going crazy trying to build gdb 5.1.1's gdbserver
in a cross-development environment.

Has anyone here build one recently?
If so, can you please post your recipe?

Thanks,
Dan

Re: How does one cross-compile gdbserver?

[Daniel Jacobowitz]

On Tue, Jan 29, 2002 at 05:28:05PM -0800, Dan Kegel wrote:
> I'm going crazy trying to build gdb 5.1.1's gdbserver
> in a cross-development environment.
> 
> Has anyone here build one recently?
> If so, can you please post your recipe?

(Just the day for this answer...)

Same way as anything else!  You need to have a compiler capable of
building target userland binaries, and a development environment set up
for same.  You may need to run configure in the gdbserver directory
manually, with CC set appropriately.  Note that you want a gdb
configured --host=<your target>, not --target=<>!

I don't give it good odds of compiling.  I've tried several times to
clean that up and gotten stymied in various people's objections to my
methods (sorry Andrew).  I'll be taking another stab at it this week I
think.

If you get it to build, drop the list a line with your platform.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: How does one cross-compile gdbserver?

[Dan Kegel]

Daniel Jacobowitz wrote:
> 
> On Tue, Jan 29, 2002 at 05:28:05PM -0800, Dan Kegel wrote:
> > I'm going crazy trying to build gdb 5.1.1's gdbserver
> > in a cross-development environment.
> >
> > Has anyone here build one recently?
> > If so, can you please post your recipe?
> 
> Same way as anything else!  You need to have a compiler capable of
> building target userland binaries, and a development environment set up
> for same.  You may need to run configure in the gdbserver directory
> manually, with CC set appropriately.  Note that you want a gdb
> configured --host=<your target>, not --target=<>!
> 
> I don't give it good odds of compiling.  I've tried several times to
> clean that up and gotten stymied in various people's objections to my
> methods (sorry Andrew).  I'll be taking another stab at it this week I
> think.

Glad someone's working on it.  (I'm hoping my company can funnel some
money to mvista soon.  Every time I turn around, Montavista is doing things
that help us.)

All I'm trying to do is build
gdbserver to run on the embedded system.  It appears that gdbserver 
won't build unless you also build gdb *for the exact same environment*,
as it shares gdb's config.h, so I build a sacrificial gdb for the
embedded system even though I never plan to run gdb itself there.
(Just configuring it should be enough, but I think it turned
out I ran into trouble if I didn't actually build it.)
Here's what I'm doing at the moment, and where I get stuck.  (This is
using Montavista Journeyman Linux 2.0 for the PowerPC 405, which does
not have floating point registers.)

1. Unpack gdb-5.1.1.
2. Apply three kludges to get around build problems:
  Edit gdb/Makefile.in to keep gdb-all from building sim.
  Edit gdb/low-linux.c to define NUM_FREGS 0 if it's not defined.
  Edit gdb/low-linux.c to redefine BYTES_REGISTER to 32000 instead
   of the nonconstant it has by default.
3. Build as follows:

mkdir nativeppc405
cd nativeppc405
CC=/opt/hardhat/devkit/ppc/405/bin/ppc_405-gcc CFLAGS="-mcpu=403"   /bin/sh ../gdb-5.1.1/configure powerpc-foo-linux-gnu
CC=/opt/hardhat/devkit/ppc/405/bin/ppc_405-gcc CFLAGS="-mcpu=403"   make all-gdb
cd ..
cd nativeppc405/gdb/gdbserver
CC=/opt/hardhat/devkit/ppc/405/bin/ppc_405-gcc CFLAGS="-mcpu=403"   /bin/sh ../../../gdb-5.1.1/gdb/gdbserver/configure powerpc-foo-linux-gnu
CC=/opt/hardhat/devkit/ppc/405/bin/ppc_405-gcc CFLAGS="-mcpu=403"  make 

This works right up until it tries to link gdbserver, at which point it fails
with undefined symbols and bad relocations:

/opt/hardhat/devkit/ppc/405/bin/ppc_405-gcc    -o gdbserver utils.o low-linux.o server.o remote-utils.o \

low-linux.o: In function `register_addr':
/home/dank/ixia/Software/Source/linux/3rdParty/gdb/nativeppc405/gdb/gdbserver/../../../gdb-5.1.1/gdb/gdbserver/low-linux.c:555: undefined reference to
`current_gdbarch'
/home/dank/ixia/Software/Source/linux/3rdParty/gdb/nativeppc405/gdb/gdbserver/../../../gdb-5.1.1/gdb/gdbserver/low-linux.c:555: undefined reference to
`current_gdbarch'
/home/dank/ixia/Software/Source/linux/3rdParty/gdb/nativeppc405/gdb/gdbserver/../../../gdb-5.1.1/gdb/gdbserver/low-linux.c:555: undefined reference to
`gdbarch_num_regs'
/home/dank/ixia/Software/Source/linux/3rdParty/gdb/nativeppc405/gdb/gdbserver/../../../gdb-5.1.1/gdb/gdbserver/low-linux.c:555: relocation truncated to fit:
R_PPC_REL24 gdbarch_num_regs
/home/dank/ixia/Software/Source/linux/3rdParty/gdb/nativeppc405/gdb/gdbserver/../../../gdb-5.1.1/gdb/gdbserver/low-linux.c:558: undefined reference to
`ppc_register_u_addr'
/home/dank/ixia/Software/Source/linux/3rdParty/gdb/nativeppc405/gdb/gdbserver/../../../gdb-5.1.1/gdb/gdbserver/low-linux.c:558: relocation truncated to fit:
R_PPC_REL24 ppc_register_u_addr
...

Any suggestions?

Thanks,
Dan

Re: How does one cross-compile gdbserver?

[Andrew Cagney]

> On Tue, Jan 29, 2002 at 05:28:05PM -0800, Dan Kegel wrote:
> 
>> I'm going crazy trying to build gdb 5.1.1's gdbserver
>> in a cross-development environment.
>> 
>> Has anyone here build one recently?
>> If so, can you please post your recipe?
> 
> 
> (Just the day for this answer...)
> 
> Same way as anything else!  You need to have a compiler capable of
> building target userland binaries, and a development environment set up
> for same.  You may need to run configure in the gdbserver directory
> manually, with CC set appropriately.  Note that you want a gdb
> configured --host=<your target>, not --target=<>!
> 
> I don't give it good odds of compiling.  I've tried several times to
> clean that up and gotten stymied in various people's objections to my
> methods (sorry Andrew).  I'll be taking another stab at it this week I
> think.


:-)

I've been thinking about making it obsolete.  Not that I want to lose 
it.  Rather that it clears the slate and removes any obligation to keep 
other targets working.

The other is to just declare it really broken.

Andrew

Re: How does one cross-compile gdbserver?

[Dan Kegel]

Andrew Cagney wrote:
> 
> > On Tue, Jan 29, 2002 at 05:28:05PM -0800, Dan Kegel wrote:
> >
> >> I'm going crazy trying to build gdb 5.1.1's gdbserver
> >> in a cross-development environment.
> >
> > I don't give it good odds of compiling.  I've tried several times to
> > clean that up and gotten stymied in various people's objections to my
> > methods (sorry Andrew).  I'll be taking another stab at it this week I
> > think.
> 
> :-)
> 
> I've been thinking about making it obsolete.  Not that I want to lose
> it.  Rather that it clears the slate and removes any obligation to keep
> other targets working.

If you make gdbserver obsolete, what would you replace it with?

There's no question that some sort of remote debugging probe
is a must for embedded development (personally, I use printf,
but 90% of developers would much prefer to use a debugger).
 
- Dan

Re: How does one cross-compile gdbserver?

[Daniel Jacobowitz]

On Tue, Jan 29, 2002 at 09:27:40PM -0500, Andrew Cagney wrote:
> >On Tue, Jan 29, 2002 at 05:28:05PM -0800, Dan Kegel wrote:
> >
> >>I'm going crazy trying to build gdb 5.1.1's gdbserver
> >>in a cross-development environment.
> >>
> >>Has anyone here build one recently?
> >>If so, can you please post your recipe?
> >
> >
> >(Just the day for this answer...)
> >
> >Same way as anything else!  You need to have a compiler capable of
> >building target userland binaries, and a development environment set up
> >for same.  You may need to run configure in the gdbserver directory
> >manually, with CC set appropriately.  Note that you want a gdb
> >configured --host=<your target>, not --target=<>!
> >
> >I don't give it good odds of compiling.  I've tried several times to
> >clean that up and gotten stymied in various people's objections to my
> >methods (sorry Andrew).  I'll be taking another stab at it this week I
> >think.
> 
> 
> :-)
> 
> I've been thinking about making it obsolete.  Not that I want to lose 
> it.  Rather that it clears the slate and removes any obligation to keep 
> other targets working.
> 
> The other is to just declare it really broken.

...

Do you want me to count the number of messages last summer where I
wanted to do either of those? :)

Seriously - my opinion is that it is totally broken at the present
time, that I can fix it for one platform at a time, and that it would
be cleaner if I first declared it broken for all targets.  If you're
more open to this idea now, I'll kick into high gear on it.  I can
probably get all the Linux and most of the *BSD targets fixed; all
current-ish Solaris systems aren't even supported because gdbserver
never grokked /proc, and the other supported systems are mostly
obsolete or last tested on obsolete versions.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: How does one cross-compile gdbserver?

[Dan Kegel]

Daniel Jacobowitz wrote:
> Seriously - my opinion is that it is totally broken at the present
> time, that I can fix it for one platform at a time, and that it would
> be cleaner if I first declared it broken for all targets.  If you're
> more open to this idea now, I'll kick into high gear on it.  I can
> probably get all the Linux and most of the *BSD targets fixed; all
> current-ish Solaris systems aren't even supported because gdbserver
> never grokked /proc, and the other supported systems are mostly
> obsolete or last tested on obsolete versions.

As a dumb Linux programmer who has peeked briefly into gdbserver's code, 
I vote for declaring gdbserver totally broken on all platforms
if that's what it takes to get it fixed up cleanly.

I would of course prefer that Linux be the first OS the new
gdbserver is developed for :-)   For what it's worth,
I would like to use it with ppc405, ppc750, and sh4.
My users are starting to scream for it...

- Dan

Re: How does one cross-compile gdbserver?

[Andrew Cagney]

>> > I don't give it good odds of compiling.  I've tried several times to
>> > clean that up and gotten stymied in various people's objections to my
>> > methods (sorry Andrew).  I'll be taking another stab at it this week I
>> > think.
> 
>> 
>> :-)
>> 
>> I've been thinking about making it obsolete.  Not that I want to lose
>> it.  Rather that it clears the slate and removes any obligation to keep
>> other targets working.
> 
> 
> If you make gdbserver obsolete, what would you replace it with?


gdbserver


> There's no question that some sort of remote debugging probe
> is a must for embedded development (personally, I use printf,
> but 90% of developers would much prefer to use a debugger).


The current GDBSERVER is rapidly decaying.  This is occuring chiefly 
because core gdb is being multi-arched (multi-arch is about a GDB with 
support for multiple architectures / OSs / shlibs).

I don't think Daniel's core problem is being stymied by peoples 
objections but rather the obligation to keep (or at least try to keep) 
existing gdbservers working.

If GDBSERVER is declared obsolete or (a better way of putting it) 
completly broken then the obligation to keep things working really isn't 
relevant.

enjoy,
Andrew


PS: Daniel, did you ever do that signals.h header file?

Re: How does one cross-compile gdbserver?

[Daniel Jacobowitz]

On Wed, Jan 30, 2002 at 12:20:24AM -0500, Andrew Cagney wrote:
> 
> The current GDBSERVER is rapidly decaying.  This is occuring chiefly 
> because core gdb is being multi-arched (multi-arch is about a GDB with 
> support for multiple architectures / OSs / shlibs).
> 
> I don't think Daniel's core problem is being stymied by peoples 
> objections but rather the obligation to keep (or at least try to keep) 
> existing gdbservers working.
> 
> If GDBSERVER is declared obsolete or (a better way of putting it) 
> completly broken then the obligation to keep things working really isn't 
> relevant.

Agree on all counts.

> PS: Daniel, did you ever do that signals.h header file?

I think so.  I'll dig it up.  I don't really remember what was needed -
but I still have the entire discussion on my TODO list.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer