cvs commit: src/gnu/usr.bin/gdb/kgdb Makefile

Marcel Moolenaar marcel at xcllnt.net
Tue Nov 30 10:45:14 PST 2004


On Nov 30, 2004, at 12:34 AM, M. Warner Losh wrote:

> : I disagree. The fact that gdb is not a cross-tool in the buildworld
> : sense of the meaning is because we don't need gdb to cross-build 
> world.
> : This does not mean that gdb cannot be a cross-tool from a developers
> : point of view. In fact, it's really handy to be able to debug a 
> kernel
> : remotely when the debugger doesn't run on the same architecture as
> : the kernel. I for one do not want to have 2 machines per architecture
> : for the only reason that I want to debug a kernel remotely. So, I 
> made
> : some changes to work towards that goal. I see no problems or harm,
> : especially since I'm not misusing TARGET_ARCH. The ability to build a
> : cross-debugger is simply not utilized as part of a buildworld.
>
> But MACHINE_ARCH is set correctly during the build of gdb when you've
> set TARGET_ARCH to build the rest of the world you need to build gdb
> with.  Or am I missing something?

I'm having problems figuring out what exactly you mean and thus what
your point is. I think the following addresses your presumed point:

As soon as we do the _everything part of a buildworld both MACHINE_ARCH
and TARGET_ARCH represent the architecture we're doing the buildworld
*for* (if TARGET_ARCH is undefined, we define it as MACHINE_ARCH).
Hence, we cannot build a cross debugger as part of buildworld if we
don't do it as part of the cross-tools phase. This is also not my
immediate goal. Rather, I'm working towards an easy recipe involving
binutils, gdb and libkvm that allows building and installing a cross
debugger. By hand for now. This may or may not be given a target in
src/Makefile and may or may not evolve into something that allows
doing it during a buildworld.

-- 
  Marcel Moolenaar         USPA: A-39004          marcel at xcllnt.net



More information about the cvs-src mailing list