[K42-discussion] Problem debugging linux user mode apps with K42 remote gdb

Patrick Bozeman PEBozeman at lbl.gov
Tue Aug 29 05:54:57 EST 2006 

Not adding the symbols for libk42sys.o didn't help.  Can someone else 
confirm that they are able to break into a linux process?  Originally, I 
tried to break into the pre-compiled sshd and that didn't work either.  
(sshd was the first program that triggered the bug in my code.)

In the mean time, I'll either compile a native K42 app to debug my 
problem or throw in lots of debug statements.  (For the curious, I 
modified some bits in the ServerFiles's client data and I need to make 
sure it gets propagated during a dup call.  This currently works for 
most file types but not for null streams.  So, I'm trying to figure out 
where the client dup call made by dup2  is going for null streams.  It 
isn't going where I expected it to and I just wanted to step into the 
call to see which client class's dup method is being called.)

Patrick Bozeman wrote:
> console> file null-dup
> null-dup: ELF 64-bit MSB executable, cisco 7500, version 1 (SYSV), for 
> GNU/Linux 2.4.19, dynamically linked (uses shared libs), not stripped
>
> I'll try not adding libk42sys.so.1.dbg when I get in tomorrow.  And in 
> response to the other email, I have "single-step-mode 0" as part of my 
> hw-debug gdb function.
>
> Also, I have the same problem if I break the program using the 
> DEBUGPROC environment variable prior to running it.  The program 
> breaks right away, I can attach via gdb, but can't take a backtrace 
> (or use gdb on it in general).
>
> On Aug 27, 2006, at 11:24 AM, Bryan S Rosenburg wrote:
>
>>
>> Patrick,
>>
>> My first thought was that null-dup is a 32-bit executable.  That 
>> doesn't seem to be the case, given the way you've built it, but would 
>> you check?  It doesn't matter whether it's 32-bit or 64-bit, but if 
>> it's 32-bit you should give gdb some arbitrary 64-bit program 
>> instead.  More on that below.  Also, I've never had to add the 
>> libk42sys.so.1.dbg symbol file.  I don't know that it hurts anything, 
>> but you might try leaving that step out.
>>
>> We've never had good debugging support for actual application code, 
>> but there should be no problem debugging K42 library code triggered 
>> by the application.  I assume the breakpoint you've compiled in is in 
>> dup2.C in kitch-linux/lib/emu?  That should work just fine.  Gdb gets 
>> confused, however, if you give it a 32-bit program and then try to 
>> debug 64-bit library code.  So it's important to give gdb a 64-bit 
>> executable no matter how your actual executable is built.  I usually 
>> say "gdb <...>/tests/linux/copy.dbg" no matter what my actual test 
>> program is.  Then "add-symbol-file <,,,>/lib/exec.so.dbg".  I'm not 
>> debugging the program itself anyway, so it doesn't matter if I have 
>> the program symbols right.
>>
>> Let us know whether any of that helps.
>>
>> - Bryan
>>
>>
>>
>>
>> *Patrick Bozeman <PEBozeman at lbl.gov <mailto:PEBozeman at lbl.gov>>*
>> Sent by: k42-discussion-bounces+rosnbrg=us.ibm.com at ozlabs.org 
>> <mailto:us.ibm.com at ozlabs.org>
>>
>> 08/25/2006 04:52 PM
>> Please respond to
>> Discussion about K42 <k42-discussion at ozlabs.org 
>> <mailto:k42-discussion at ozlabs.org>>
>>
>>
>> 	
>> To
>> 	Discussion about K42 <k42-discussion at ozlabs.org 
>> <mailto:k42-discussion at ozlabs.org>>
>> cc
>> 	
>> Subject
>> 	[K42-discussion] Problem debugging linux user mode apps with K42     
>>    remote gdb
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>> I can debug native K42 apps just fine, e.g. baseServers, but am having a
>> problem with debugging linux user mode apps.  Hopefully, someone can
>> point out what I am doing wrong.
>>
>> Thanks.
>>
>> #
>> # I compile the app with debug support.  This is a small program that
>> triggers
>> # a problem between dup2 and some other code I added to K42 file
>> # system layers.
>> #
>> console>  powerpc64-linux-gcc -g null-dup.c -o null-dup
>>
>> #
>> # I run the app..
>> #
>> k42> /tmp/null-dup
>>
>> #
>> # An asert I added to dup2.C gets triggered.  (Note, nothing about the
>> # process should be corrupt, this is just to serve as a condidtional
>> # break point to kick off debugging.)
>> #
>> # K42 hw console output...
>> #
>> breakpoint pid 0x1f, progName /tmp/null-dup
>> GDB got trap: Program Interrupt
>> vector=0x700, sr=0x900000000002f032, pc=0x1000702e18b4 lr=0x1000702e1880
>> User program pid=31(0x1f) connecting to GDB via port 2223
>>
>> #
>> # I attach via gdb and it complains a litte bit..
>> # note that the symbol files for exec.so.dbg and libk42sys.so.1.dbg are
>> added.
>> #
>> console> powerpc64-linux-gdb null-dup
>> (gdb) hw-debug 10.0.0.2:2223
>> The target architecture is assumed to be powerpc:a35
>> add symbol table from file
>> "/home/peb/src/k42-devel/k42/powerpc/partDeb/lib/exec.so.dbg" at
>> add symbol table from file
>> "/home/peb/src/k42-devel/k42/powerpc/partDeb/lib/libk42sys.so.1.dbg" at
>> <signal handler called>
>> warning: Unable to find dynamic linker breakpoint function.
>> GDB will be unable to debug shared library initializers
>> and track explicitly loaded dynamic code.
>> Current language:  auto; currently c++
>>
>> #
>> # I try to get a back trace and both gdb and the k42 hw console complain
>> #
>> (gdb) bt
>> #0  <signal handler called>
>> #1  0x2fa0000040be001c in ?? ()
>> #2  0x2fad000040be001c in ?? ()
>> Previous frame identical to this frame (corrupt stack?)
>>
>> #
>> # hw console output as a result of the bt
>> #
>> /home/peb/src/k42-devel/k42/kitchsrc/os/kernel/proc/ProcessReplicated.C,565: 
>>
>> Invalid memory access: processID 0x1f addr 0x0, type 200000 vp=0
>> this=0x8002000020790a00 myRoot=0x8002000000376a00 
>> myRef=0x8000000010001f50
>> WARNING: file
>> "/home/peb/src/k42-devel/k42/kitchsrc/os/kernel/exception/ExceptionLocal.C", 
>>
>> line 352
>> User-mode bad-address fault: commID 0x1f00000000, pc 0x1000702e852c,
>> addr 0, rc 8000000005cd6416.
>> /home/peb/src/k42-devel/k42/kitchsrc/os/kernel/proc/ProcessReplicated.C,565: 
>>
>> Invalid memory access: processID 0x1f addr 0x0, type 200000 vp=0
>> this=0x8002000020790a00 myRoot=0x8002000000376a00 
>> myRef=0x8000000010001f50
>> WARNING: file
>> "/home/peb/src/k42-devel/k42/kitchsrc/os/kernel/exception/ExceptionLocal.C", 
>>
>> line 352
>> User-mode bad-address fault: commID 0x1f00000000, pc 0x1000702e852c,
>> addr 0, rc 8000000005cd6416.
>>
>> _______________________________________________
>> K42-discussion mailing list
>> K42-discussion at ozlabs.org <mailto:K42-discussion at ozlabs.org>
>> https://ozlabs.org/mailman/listinfo/k42-discussion
>>
>> _______________________________________________
>> K42-discussion mailing list
>> K42-discussion at ozlabs.org <mailto:K42-discussion at ozlabs.org>
>> https://ozlabs.org/mailman/listinfo/k42-discussion
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> K42-discussion mailing list
> K42-discussion at ozlabs.org
> https://ozlabs.org/mailman/listinfo/k42-discussion
>

More information about the K42-discussion mailing list