I would like to send this patch into the gdb folks to make
cross-compilation of gdb for the hurd more friendly. Would you guys mind
taking a look at letting me know if I've missed anything? I particular,
if you know of a better case for testing for Hurd's host triple and
succesfully distingu
> As I haven't seen any success reports for the pfinet rework, I figured I
> would post one:
>
> I have successfully downloaded gdb (9.9MB) in the Hurd with no corruption
> (The file un bzip'd succesfully).
I'm glad to hear it. Please note that I have seen a few hiccups myself and
you might l
As I haven't seen any success reports for the pfinet rework, I figured I
would post one:
I have successfully downloaded gdb (9.9MB) in the Hurd with no corruption
(The file un bzip'd succesfully).
GNUMach from Marcus' tarball
Hurd from CVS yesterday cross compiled from Linux using Gcc-2.95.2 (
> I'm not so familiar with gdb aside from bt, print, break, step and cont.
If you show us the backtrace, that might well be all we need to know.
> Is there anyway to cause it to log the session to a file?
Try `script gdb'.
On Fri, Feb 25, 2000 at 04:13:44PM -0500, Roland McGrath wrote:
I'm not so familiar with gdb aside from bt, print, break, step and cont.
Is there anyway to cause it to log the session to a file?
> The most useful thing you can do is try to run your the system in a
> sub-hurd, while watching it
The most useful thing you can do is try to run your the system in a
sub-hurd, while watching it using ps and gdb from the working hurd. Since
the sub-hurd is never going to make it all the way up, you don't even
really need to make a separate filesystem for it; you can just boot the
sub-hurd read
'proc' fails on startup when compiled with gcc-2.95.2, either natively or
cross-compiled. Replacing it with one cross compiled from egcs-1.1.2
gives me a full-functioning system (I don't have to recompile any of the
support libraries).
After the GNUMach bit, I get the following:
Hurd server
