Date: Sun, 21 Oct 2012 10:32:46 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Problem Compiling gdbserver with musl On Sun, Oct 21, 2012 at 05:19:37PM +0800, Brian Wang wrote: > >> thread-db.c: In function ‘thread_db_handle_monitor_command’: > >> thread-db.c:971:7: error: ‘LIBTHREAD_DB_SEARCH_PATH’ undeclared (first > >> use in this function) > >> thread-db.c: In function ‘try_thread_db_load_from_sdir’: > >> thread-db.c:709:1: error: control reaches end of non-void function > >> [-Werror=return-type] > >> cc1: all warnings being treated as errors > >> -------------- > >> > > > > hello brian, please forward your bug report to gdb mailing list. > > clearly gdb devs should check if these facilities are available before using > > them. > > we must raise awareness of such issues upstream. > > I guess gdb development is somehow tightly coupled with glibc, which > supplies libthread_db. > I remember seeing similar issues reported: > http://sourceware.org/bugzilla/show_bug.cgi?id=13011 Well, on Linux it's tightly coupled. The (bad) design for this seems to have been copied from Solaris (big surprise). I think a middle ground should be possible -- the highly-invasive control over threads gdb wants to offer seems hard or impossible to do without support from the program being debugged, but minimal awareness of threads, switching between threads and viewing their stack frames, etc. can and should be supported in gdb without a special thread-debugging backdoor. > > as a temporary fix, you can either build gdb without gdbserver: > > https://github.com/rofl0r/sabotage/blob/master/pkg/gdb > > > > patches are here: https://github.com/rofl0r/sabotage/tree/master/KEEP > > > > before i ported sabotage to mips i had working patches for gdbserver to > > *compile* (did not test if it *works*) on x86 and amd64: > > > > https://github.com/rofl0r/sabotage/commit/02202d48d5062c62a3fa62deaf3bdc01d5b4423d > > > > the dlopen patch should not be necessary with current musl. > > Thank you for the pointers. :-) > > gdbserver+gdb now works for my ARM target, at least for > single-thread program. Nice to hear! I think it will work for multi-threaded programs too, but you'll have a hard time inspecting individual thread states. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.