How to debug networking codes?

Wed Aug 29 08:51:36 UTC 2007

Lately remote debugging using serial port worked for me. I was using init_remote_gdb() API to initialize gdb for serial port in target machine and it was initializing COM2 internally. But my machine has only COM1. Hence initializing GDB for COM1 instead of COM2 worked straight!

Thanks!

-----Original Message-----
From: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
Sent: Monday, August 27, 2007 6:27 AM
To: Till Straumann
Cc: Rahman, Md Sazzadur; rtems-users at rtems.com; Atiquzzaman, Mohammed
Subject: Re: How to debug networking codes?

Till Straumann wrote:
> Rahman, Md Sazzadur wrote:
>
>> Hi,
>>
>> Thanks for your suggestion. Lately I was trying to debug networking codes for SCTP in RTEMS via serial port using rtems_gdb_stub_1.4(http://www.slac.stanford.edu/~strauman/rtems/gdb/index.html). But, I was not able to connect target machine from the host using serial port although I was able to connect them using TCP/IP.
>>
>> In target init.c: I have added,
>>
>>
>>         init_remote_gdb(); //just to initialize serial port in RTEMS. It is defined:    /c/src/lib/libbsp/i386/shared/comm/gdb_glue.c
>>
>>
> I don't recall what this routine does and if it is compatible with
> my stub. I'd have to check...
>
Those are regular gdb stubs that have been modified to make them
RTEMS thread aware.  You should use "target remote" or
"target extended-remote".

With those, you should have a chance at debugging a network driver.
But you can't debug a network driver while simultaneously using it
to debug.  Till's debug server is over TCP/IP.
>>         rtems_gdb_start(0,"/dev/ttyS0");
>>         rtems_gdb_breakpoint();
>>
>> The console shows:
>>         GDB daemon (Release $Name: RTEMS_gdb_stub_1_4 $): starting up
>>
>>
>> In host: I was running GDB6.6 for target i386-ssrl-rtems
>>
>>
>>
> did you set the baudrate of the host gdb to 115200 ?
>
> T.
>
>>         (gdb) target rtems-remote /dev/ttyS0
>>         Remote debugging using /dev/ttyS0
>>         Ignoring packet error, continuing...
>>         warning: unrecognized item "timeout" in "qSupported" response
>>         Ignoring packet error, continuing...
>>         Ignoring packet error, continuing...
>>         Ignoring packet error, continuing...
>>         Malformed response to offset query, timeout
>>         (gdb)
>>
>> //      Using   /dev/ttyS0 of this host, I could transfer and receive data with other Linux machines.
>>
>> Is there anything I am missing here? I would appreciate any help in this regard.
>>
>> -Sazzad
>>
>> -----Original Message-----
>> From: Till Straumann [mailto:strauman at slac.stanford.edu]
>> Sent: Wednesday, August 22, 2007 12:20 PM
>> To: Rahman, Md S.
>> Cc: rtems-users at rtems.com
>> Subject: Re: How to debug networking codes?
>>
>> RTM.
>>
>> You cannot debug networking code. If you set a breakpoint in
>> networking and e.g., the network task is suspended at the breakpoint
>> -- how do you expect the stub to continue talking to the host gdb
>> using the same network stack???
>>
>> If you want to debug networking then you should use GDB on a serial
>> connection (preferrably a separate serial port where no printf/printk
>> is directed).
>>
>> HTH
>> -- Till
>>
>> Rahman, Md S. wrote:
>>
>>
>>> Hello,
>>>
>>> I have been porting SCTP(Stream Control Transmission Protocol) in
>>> RTEMS from FreeBSD. This is a transport layer protocol and resides
>>> with TCP/UDP networking codes in kernel. I am mostly done with this
>>> port and a number of SCTP socket API's like socket, listen, bind,
>>> accept, connect etc. works fine.
>>>
>>> However, I am now encountering some exception problems while
>>> establishing SCTP connection between RTEMS SCTP endpoint with FreeBSD
>>> SCTP endpoint via internet. The console shows:
>>>
>>> Exception 6 caught at PC 191864 by Thread 167831697
>>>
>>> Processor execution context at time of the fault was:
>>>
>>> EAX 340012E7 EBX=384 ECX=FFFFFFFF EX=0
>>>
>>> ESI=0 EDI=0 EBP=195838 ESP=195804
>>>
>>> Error code pushed by processor itself (if not 0) = 0
>>>
>>> Faulty Thread will be deleted
>>>
>>> I tried to debug this problem by adding printf in codes but was not
>>> able to detect the exact statement which causes this exception. Then I
>>> have built RTEMS_GDB_Stub_1.4
>>> (http://www.slac.stanford.edu/~strauman/rtems/gdb/index.html
>>> <http://www.slac.stanford.edu/%7Estrauman/rtems/gdb/index.html>) for
>>> remote debugging and built my RTEMS SCTP application with
>>> librtems-gdb-stub.a library. At this point, running the RTEMS
>>> application crashes with:
>>>
>>> GDB Agent: Exception (SIGILL) caught; Task 0xA010001 Killed
>>> (Suspended) -use GDB
>>>
>>> Exception Vector #0x6; Registers:
>>>
>>> .....................
>>>
>>> To investigate further with breakpoints, I have configured gdb6.6
>>> patched with RTEMS_GDB_Stub_1.4 in the host machine FC5. This works
>>> fine and any break point in RTEMS application in init.c could be
>>> reachable by the host gdb. However, when I try to reach a breakpoint
>>> in SCTP code which resides in cpukit/libnetworking/netinet, host gdb
>>> loses connection with the target machine and target application dies.
>>>
>>> In this point, I am not sure how should I proceed to solve this problem.
>>>
>>> I would appreciate any suggestion in this regard.
>>>
>>> Best Regards,
>>>
>>> Md Sazzadur Rahman
>>>
>>> Graduate Student,
>>>
>>> School of Computer Science,
>>>
>>> University of Oklahoma,
>>>
>>> Norman, Oklahoma, USA
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.com
>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>
>>>
>>>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>