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

[Patrick Bozeman]

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>
> Sent by: k42-discussion-bounces+rosnbrg=us.ibm.com at ozlabs.org
> 08/25/2006 04:52 PM
> Please respond to
> Discussion about K42 <k42-discussion at ozlabs.org>
>
>
> To
> Discussion about K42 <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
> https://ozlabs.org/mailman/listinfo/k42-discussion
>
> _______________________________________________
> K42-discussion mailing list
> K42-discussion at ozlabs.org
> https://ozlabs.org/mailman/listinfo/k42-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ozlabs.org/pipermail/k42-discussion/attachments/20060827/9b8ea76d/attachment.htm