Re: Firewire blues
From: Gerald Heinig (gheinig_at_syskonnect.de)
Date: 02/14/05
- Previous message: Varshavchick Alexander: "netstat info weird"
- In reply to: Stephan Uphoff: "Re: Firewire blues"
- Next in thread: Gerald Heinig: "Re: Firewire blues"
- Reply: Gerald Heinig: "Re: Firewire blues"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 14 Feb 2005 17:19:17 +0100 To: Stephan Uphoff <ups@tree.com>
Hi Stephan,
first off, thanks very much for your continuing help on this. It's very
much appreciated.
I compiled a kernel with exactly the same options that you cited below.
I tried booting it and it stops before the kernel probe routines and
waits for the FireWire GDB connect.
I can't understand how you managed to reboot the target machine without
it entering the debugger and waiting for the remote gdb attach. My
machine refuses to do anything else.
I tried unsetting boot_ddb and boot_gdb in the loader, as well as
clearing the -d and -g flags in the boot_flags variable. No deal, it
still stops and waits for the remote gdb attach.
When I try to attach from the debug machine, gdb complains about
operation not supported.
Also, I don't understand how your command line
kgdb -r :5555 -t 11-22-33-44-55...
can work. I just get
':5555: no such file or directory'
when I try that. The kgdb manpage also states that it needs a device
after the -r option, so I presume your kgdb version works somewhat
differently to mine.
I tried the following devices after kgdb's -r option:
/dev/fwmem0.0, /dev/fw0, /dev/net/fwe0, /dev/net/fwip0
None worked.
I tried taking the dcons/dcons_crom options out of the kernel and
loading the corresponding modules before booting the kernel. This sort
of worked in that I could then start a dconschat session on the debug
machine and enter the ddb debugger. Switching to gdb didn't work, since
the gdb backend was missing. When the kernel booted, it complained about
there being no debug ports for gdb present, so it didn't enable the gdb
backend support.
Stephan Uphoff wrote:
>
>
> OK - I finally managed to try this on a newly installed 5.3-RELEASE.
>
> I copied the GENERIC config file (to GENERIC.debug) and added a few
> lines
>
> diff -u GENERIC GENERIC.debug
> --- GENERIC Sun Oct 24 14:02:52 2004
> +++ GENERIC.debug Mon Feb 14 03:15:21 2005
> @@ -24,6 +24,14 @@
> cpu I686_CPU
> ident GENERIC
>
> +makeoptions DEBUG=-g # Build kernel with gdb(1)
> debug symbols
> +options KDB # Enable kernel debugger
> support.
> +options DDB # Support DDB.
> +options GDB # Support remote GDB.
> +options ALT_BREAK_TO_DEBUGGER
> +device dcons
> +device dcons_crom
> +
> # To statically compile in device wiring instead of /boot/device.hints
> #hints "GENERIC.hints" # Default places to look for
> devices.
>
This is pretty much what I had before.
>
> Then configured/compiled/installed the GENERIC.debug kernel.
> Copied the kernel.debug file in the GENERIC.debug compile directory to
> the debug station and rebooted the target machine.
Why does your machine boot without waiting for a debug connection? With
the debug options mentioned above, my kernel waits for the remote
Firewire gdb connection here, which doesn't work.
Are there any loader flags I have to set?
>
> After reboot I set the default debugger to gdb
>
> target# sysctl -w debug.kdb.current=gdb
> and entered the debugger
> target# sysctl -w debug.kdb.enter=1
>
>
> On the debugging station I entered
> debug 1# dconschat -br -G 5555 -t <firewire address of target>
>
> and then in another window
> debug 2# kgdb -r :5555 kernel.debug
---------------------------^^^^^
This doesn't work on my system: kgdb complains about ':5555 : no such
file or directory'
>
> And it just worked for me.
> I have to admit that my debugging machine is not 5.3 .. but I believe I
> used the same setup with pre 5.3 userland before.
>
> Let me know if you can repeat my steps.
> If not then I can set up a 5.3 debugging station in the next days.
Thanks again for your patience.
Cheers,
Gerald
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
- Previous message: Varshavchick Alexander: "netstat info weird"
- In reply to: Stephan Uphoff: "Re: Firewire blues"
- Next in thread: Gerald Heinig: "Re: Firewire blues"
- Reply: Gerald Heinig: "Re: Firewire blues"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
- Re: DDD debugger problem
... Ioannis Hadjichambis wrote: ... > I am trying to debug my program
using the DDD debugger. ... > (gdb) set args ... (comp.lang.c) - Re: dde Debug message
... The DDE is the absolute worst debugger I have ever used. ... it is the only
one that can debug MT apps on hpux 10.20 ... The other thing you can do is run the app
under gdb until it SIGSERVs ... In order to understand recursion you must first
understand recursion. ... (comp.unix.programmer) - Debugging problems on amd64-current
... Updating to a 7.0-current/amd64 kernel did allow it to be recognized and I've been
able to use it. ... If I used gdb and stepped after a segfault, ... I could debug
but just had to mind myself. ... FreeBSD is a registered trademark of The FreeBSD Foundation.
... (freebsd-hackers) - Re: FreeBSD 7.0 Beta, RC, RELEASE (amd64) freezes with dummynet enabled
... I have some screenshots from debug console after the ... [GDB will not
be able to debug user-mode threads: ... KDB: enter: manual escape to debugger ...
I disabled the polling, for my suprise, the server didn`t crashed after some minutes, but after
1 hour, but crushed, maybe only a coincidence, but maybe not. ... (freebsd-current) - Re: Unable to get debug message which is in kernel
... kernel image on to the target and I have ensured that ARMInit function ... I
don't get the debug message " ARMInit done" printed on the ... I take it that you have
no JTAG debugger? ... I am using the same OEMDebugInit, OEMWriteDebugString, ...
(microsoft.public.windowsce.platbuilder)