This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>Thanks! I think you just saved me a lot of time. >(I'm just hoping I didn't have some intelligent reason for >leaving out install-others that I'm forgetting.) That's what happens when we're out on the bleeding edge. I don't see adding install-others causing trouble, but I'm only doing it for ColdFire, and don't know if it breaks any of the other architecture builds. I have glibc-2.3.5 working with an add-on for ColdFire, but I'm having a bitch of a time trying to get LTP (Linux Test Project) to run since it seems that any pthread program (LTPs 'pan' program in this case) hangs on startup, and gdbserver isn't quite working for me with gdb-6.3. What's even weirder is if I telnet to the board and cat the process map while pan is running, it suddenly unwedges and moves further. Really *weird*! Using strace on it shows its stuck in 'testandset' since I see batches of calls to yeild and nanosleep. The rest of the system works fine (nfs, ps, bash, etc), so I'm assuming my problem is pthread specific and has nothing to do with dynamic linking. Does anyone have a pointer to a cheat-sheet for how to debug a process from scratch using gdbserver? I'm stuck in the midst of ld-2.3.5.so, libpthread-0.10.so, and libc-2.3.5.so, and I'd *really* love to get source displayed, even though I've: (gdb) set solib-absolute-prefix=/dev/null/ (gdb) set solib-search-path /opt/logicpd/ColdFire-new14/m68k-linux/gcc-3.4.3-glibc-2.3.5/m68k-linux/lib (gdb) file /tmp/pan Reading symbols from /tmp/pan...done. (gdb) tar remo 192.168.3.10:3001 Remote debugging using 192.168.3.10:3001 0x40002240 in ?? () (gdb) b getopt Breakpoint 1 at 0x800013bc (gdb) c Continuing. Ignoring packet error, continuing... Error in re-setting breakpoint 1: Reply contains invalid hex digit 113 Breakpoint 1 at 0x40114b58 Breakpoint 1 at 0x40114b5c [New Thread 16384] Program received signal SIGINT, Interrupt. [Switching to Thread 16384] 0x40027d1e in nanosleep () from /opt/logicpd/ColdFire-new14/m68k-linux/gcc-3.4.3-glibc-2.3.5/m68k-linux/lib/libpthread.so.0 (gdb) Quit (gdb) where 10 #0 0x40027d1e in nanosleep () from /opt/logicpd/ColdFire-new14/m68k-linux/gcc-3.4.3-glibc-2.3.5/m68k-linux/lib/libpthread.so.0 #1 0x40025716 in __pthread_acquire () from /opt/logicpd/ColdFire-new14/m68k-linux/gcc-3.4.3-glibc-2.3.5/m68k-linux/lib/libpthread.so.0 #2 0x400258b6 in __pthread_alt_lock () from /opt/logicpd/ColdFire-new14/m68k-linux/gcc-3.4.3-glibc-2.3.5/m68k-linux/lib/libpthread.so.0 #3 0x40021692 in pthread_mutex_lock () from /opt/logicpd/ColdFire-new14/m68k-linux/gcc-3.4.3-glibc-2.3.5/m68k-linux/lib/libpthread.so.0 #4 0x400a4f70 in __new_exitfn () from /opt/logicpd/ColdFire-new14/m68k-linux/gcc-3.4.3-glibc-2.3.5/m68k-linux/lib/libc.so.6 #5 0x400a4fec in __cxa_atexit_internal () from /opt/logicpd/ColdFire-new14/m68k-linux/gcc-3.4.3-glibc-2.3.5/m68k-linux/lib/libc.so.6 #6 0x4008dfb4 in __libc_start_main () from /opt/logicpd/ColdFire-new14/m68k-linux/gcc-3.4.3-glibc-2.3.5/m68k-linux/lib/libc.so.6 #7 0x80001772 in _start () (gdb) I had to ^C to get back to GDB so I could see where it is. I would have figured if GDB has enough info to tell where the library its coming from that it should have all the debug info(source file-n-line). I know that on the host the libraries are not stripped, but on the target they are to save space. Any suggestions are appreciated! -- Peter Barada peter@the-baradas.com ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |