Re: Problem Compiling gdbserver with musl

[Rich Felker <dalias@aerifal.cx>]

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