Problem Compiling gdbserver with musl

Problem Compiling gdbserver with musl

[Brian Wang]

Hello all,

Is it possible to cross compile gdbserver with musl?  I tried it and
it failed complaining about some thread-db stuff:
--------------
thread-db.c: In function ‘find_one_thread’:
thread-db.c:292:7: error: format ‘%ld’ expects argument of type ‘long
int’, but argument 3 has type ‘thread_t’ [-Werror=format]
thread-db.c:315:6: error: ‘struct lwp_info’ has no member named ‘th’
thread-db.c: In function ‘attach_thread’:
thread-db.c:329:7: error: format ‘%ld’ expects argument of type ‘long
int’, but argument 3 has type ‘thread_t’ [-Werror=format]
thread-db.c:335:9: error: format ‘%ld’ expects argument of type ‘long
int’, but argument 2 has type ‘thread_t’ [-Werror=format]
thread-db.c:340:6: error: ‘struct lwp_info’ has no member named ‘th’
thread-db.c: In function ‘thread_db_get_tls_address’:
thread-db.c:513:47: error: ‘struct lwp_info’ has no member named ‘th’
thread-db.c: In function ‘dladdr_to_soname’:
thread-db.c:652:3: error: passing argument 1 of ‘dladdr’ discards
‘const’ qualifier from pointer target type [-Werror]
In file included from thread-db.c:33:0:
/opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/dlfcn.h:30:5:
note: expected ‘void *’ but argument is of type ‘const void *’
thread-db.c: In function ‘try_thread_db_load_from_sdir’:
thread-db.c:708:30: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
this function)
thread-db.c:708:30: note: each undeclared identifier is reported only
once for each function it appears in
thread-db.c: In function ‘try_thread_db_load_from_dir’:
thread-db.c:719:29: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
this function)
thread-db.c: In function ‘thread_db_load_search’:
thread-db.c:748:41: error: ‘LIBTHREAD_DB_SEARCH_PATH’ undeclared
(first use in this function)
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
--------------

Is there a separate libthread_db library for musl?

Thank you.


Brian

-- 
brian
------------------

Cool-Karaoke - The smallest recording studio, in your palm, open-sourced
http://cool-idea.com.tw/

iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe

Re: Problem Compiling gdbserver with musl

[Rich Felker]

On Fri, Oct 19, 2012 at 02:13:12PM +0800, Brian Wang wrote:
> Hello all,
> 
> Is it possible to cross compile gdbserver with musl?  I tried it and
> it failed complaining about some thread-db stuff:

I'm not sure how to get gdb to build on musl. I have not done it
myself, but I've heard that some of musl's users/packagers have done
it. Hopefully someone else can jump in with a good answer.

> --------------
> thread-db.c: In function ‘find_one_thread’:
> thread-db.c:292:7: error: format ‘%ld’ expects argument of type ‘long
> int’, but argument 3 has type ‘thread_t’ [-Werror=format]

These are because gdb assumes pthread_t is an integer type. musl uses
an opaque pointer type, both for convenience and robustness against
common programming errors (the compiler can report mixups/misordering
of arguments much better).

> thread-db.c:652:3: error: passing argument 1 of ‘dladdr’ discards
> ‘const’ qualifier from pointer target type [-Werror]

Not sure what caused this one.

> In file included from thread-db.c:33:0:
> /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/dlfcn.h:30:5:
> note: expected ‘void *’ but argument is of type ‘const void *’
> thread-db.c: In function ‘try_thread_db_load_from_sdir’:
> thread-db.c:708:30: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
> this function)
> [...]
> --------------
> 
> Is there a separate libthread_db library for musl?

No, and I have not yet figured out what it would entail to get gdb
supporting threads better with musl. Implementing the full
libpthread_db interface glibc provides would be very invasive in terms
of size and possibly performance. But hopefully it's possible to get
it working quite well without so much. Are you aware of any
documentation on what gdb really needs?

FYI, thread debugging support code is not necessary to get gdb
working; it's only necessary for the debugger to support interaction
with threads at runtime.

Rich

Re: Problem Compiling gdbserver with musl

[John Spencer]

On 10/19/2012 08:13 AM, Brian Wang wrote:
> Hello all,
>
> Is it possible to cross compile gdbserver with musl?  I tried it and
> it failed complaining about some thread-db stuff:
> --------------
> thread-db.c: In function ‘find_one_thread’:
> thread-db.c:292:7: error: format ‘%ld’ expects argument of type ‘long
> int’, but argument 3 has type ‘thread_t’ [-Werror=format]
> thread-db.c:315:6: error: ‘struct lwp_info’ has no member named ‘th’
> thread-db.c: In function ‘attach_thread’:
> thread-db.c:329:7: error: format ‘%ld’ expects argument of type ‘long
> int’, but argument 3 has type ‘thread_t’ [-Werror=format]
> thread-db.c:335:9: error: format ‘%ld’ expects argument of type ‘long
> int’, but argument 2 has type ‘thread_t’ [-Werror=format]
> thread-db.c:340:6: error: ‘struct lwp_info’ has no member named ‘th’
> thread-db.c: In function ‘thread_db_get_tls_address’:
> thread-db.c:513:47: error: ‘struct lwp_info’ has no member named ‘th’
> thread-db.c: In function ‘dladdr_to_soname’:
> thread-db.c:652:3: error: passing argument 1 of ‘dladdr’ discards
> ‘const’ qualifier from pointer target type [-Werror]
> In file included from thread-db.c:33:0:
> /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/dlfcn.h:30:5:
> note: expected ‘void *’ but argument is of type ‘const void *’
> thread-db.c: In function ‘try_thread_db_load_from_sdir’:
> thread-db.c:708:30: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
> this function)
> thread-db.c:708:30: note: each undeclared identifier is reported only
> once for each function it appears in
> thread-db.c: In function ‘try_thread_db_load_from_dir’:
> thread-db.c:719:29: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
> this function)
> thread-db.c: In function ‘thread_db_load_search’:
> thread-db.c:748:41: error: ‘LIBTHREAD_DB_SEARCH_PATH’ undeclared
> (first use in this function)
> 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.


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.

Re: Problem Compiling gdbserver with musl

[John Spencer]

On 10/19/2012 03:54 PM, John Spencer wrote:
> On 10/19/2012 08:13 AM, Brian Wang wrote:
>> Hello all,
>>
>> Is it possible to cross compile gdbserver with musl?  I tried it and
>> it failed complaining about some thread-db stuff:
>> --------------
>> thread-db.c: In function ‘find_one_thread’:
>> thread-db.c:292:7: error: format ‘%ld’ expects argument of type ‘long
>> int’, but argument 3 has type ‘thread_t’ [-Werror=format]
>> thread-db.c:315:6: error: ‘struct lwp_info’ has no member named ‘th’
>> thread-db.c: In function ‘attach_thread’:
>> thread-db.c:329:7: error: format ‘%ld’ expects argument of type ‘long
>> int’, but argument 3 has type ‘thread_t’ [-Werror=format]
>> thread-db.c:335:9: error: format ‘%ld’ expects argument of type ‘long
>> int’, but argument 2 has type ‘thread_t’ [-Werror=format]
>> thread-db.c:340:6: error: ‘struct lwp_info’ has no member named ‘th’
>> thread-db.c: In function ‘thread_db_get_tls_address’:
>> thread-db.c:513:47: error: ‘struct lwp_info’ has no member named ‘th’
>> thread-db.c: In function ‘dladdr_to_soname’:
>> thread-db.c:652:3: error: passing argument 1 of ‘dladdr’ discards
>> ‘const’ qualifier from pointer target type [-Werror]
>> In file included from thread-db.c:33:0:
>> /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/dlfcn.h:30:5: 
>>
>> note: expected ‘void *’ but argument is of type ‘const void *’
>> thread-db.c: In function ‘try_thread_db_load_from_sdir’:
>> thread-db.c:708:30: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
>> this function)
>> thread-db.c:708:30: note: each undeclared identifier is reported only
>> once for each function it appears in
>> thread-db.c: In function ‘try_thread_db_load_from_dir’:
>> thread-db.c:719:29: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
>> this function)
>> thread-db.c: In function ‘thread_db_load_search’:
>> thread-db.c:748:41: error: ‘LIBTHREAD_DB_SEARCH_PATH’ undeclared
>> (first use in this function)
>> 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.
>
>
> 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 
>
this is the old patch: 
https://github.com/rofl0r/sabotage/blob/aaf55b802c7426064a15f02173f74f0d187ed55e/KEEP/gdb-patch
so you'll need at least the workarounds for the lwp_info accesses as in 
this patch, the patch that adds LIBTHREAD_DB_SEARCH_PATH and 
LIBTHREAD_DB_SO,
and of course --disable-werror. the pthread_t -> long casts don't hurt, 
an explicit (long) cast before the pthread_t type would mute the warning 
as well (i sent a patch that addresses this to gdb maillist a while 
back; it was ignored)

thread-db.c:652:3: error: passing argument 1 of ‘dladdr’ discards
‘const’ qualifier from pointer target type [-Werror]

this warning is interesting, it suggests that we have a different 
declaration here than glibc; since apparently on glibc you dont get this 
warning.

>
> the dlopen patch should not be necessary with current musl.
>

Re: Problem Compiling gdbserver with musl

[Brian Wang]

On Fri, Oct 19, 2012 at 8:30 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Fri, Oct 19, 2012 at 02:13:12PM +0800, Brian Wang wrote:
>> Hello all,
>>
>> Is it possible to cross compile gdbserver with musl?  I tried it and
>> it failed complaining about some thread-db stuff:
>
> I'm not sure how to get gdb to build on musl. I have not done it
> myself, but I've heard that some of musl's users/packagers have done
> it. Hopefully someone else can jump in with a good answer.

gdb cross compiles just fine for ARM target.  It is gdbserver that is
causing the trouble.

>
>> --------------
>> thread-db.c: In function ‘find_one_thread’:
>> thread-db.c:292:7: error: format ‘%ld’ expects argument of type ‘long
>> int’, but argument 3 has type ‘thread_t’ [-Werror=format]
>
> These are because gdb assumes pthread_t is an integer type. musl uses
> an opaque pointer type, both for convenience and robustness against
> common programming errors (the compiler can report mixups/misordering
> of arguments much better).
>
>> thread-db.c:652:3: error: passing argument 1 of ‘dladdr’ discards
>> ‘const’ qualifier from pointer target type [-Werror]
>
> Not sure what caused this one.
>
>> In file included from thread-db.c:33:0:
>> /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/dlfcn.h:30:5:
>> note: expected ‘void *’ but argument is of type ‘const void *’
>> thread-db.c: In function ‘try_thread_db_load_from_sdir’:
>> thread-db.c:708:30: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
>> this function)
>> [...]
>> --------------
>>
>> Is there a separate libthread_db library for musl?
>
> No, and I have not yet figured out what it would entail to get gdb
> supporting threads better with musl. Implementing the full
> libpthread_db interface glibc provides would be very invasive in terms
> of size and possibly performance. But hopefully it's possible to get
> it working quite well without so much. Are you aware of any
> documentation on what gdb really needs?

Sorry.  I have not got time to dig into gdb's internals.

>
> FYI, thread debugging support code is not necessary to get gdb
> working; it's only necessary for the debugger to support interaction
> with threads at runtime.

Yes, you are correct!  I just commented out those complained parts
about thread_db
and gdbserver does work, at least for a single thread program.  It is
a good-enough simple workaround
to get me started debugging a problem with Xfbdev on ARM.  Xfbdev
somehow fails to find a valid
framebuffer when cross compiled with musl...  Got to dig deeper into
the problem. :-)

Thanks.


Brian

-- 
brian
------------------

Cool-Karaoke - The smallest recording studio, in your palm, open-sourced
http://cool-idea.com.tw/

iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe

Re: Problem Compiling gdbserver with musl

[Brian Wang]

On Fri, Oct 19, 2012 at 9:54 PM, John Spencer <maillist-musl@barfooze.de> wrote:
> On 10/19/2012 08:13 AM, Brian Wang wrote:
>>
>> Hello all,
>>
>> Is it possible to cross compile gdbserver with musl?  I tried it and
>> it failed complaining about some thread-db stuff:
>> --------------
>> thread-db.c: In function ‘find_one_thread’:
>> thread-db.c:292:7: error: format ‘%ld’ expects argument of type ‘long
>> int’, but argument 3 has type ‘thread_t’ [-Werror=format]
>> thread-db.c:315:6: error: ‘struct lwp_info’ has no member named ‘th’
>> thread-db.c: In function ‘attach_thread’:
>> thread-db.c:329:7: error: format ‘%ld’ expects argument of type ‘long
>> int’, but argument 3 has type ‘thread_t’ [-Werror=format]
>> thread-db.c:335:9: error: format ‘%ld’ expects argument of type ‘long
>> int’, but argument 2 has type ‘thread_t’ [-Werror=format]
>> thread-db.c:340:6: error: ‘struct lwp_info’ has no member named ‘th’
>> thread-db.c: In function ‘thread_db_get_tls_address’:
>> thread-db.c:513:47: error: ‘struct lwp_info’ has no member named ‘th’
>> thread-db.c: In function ‘dladdr_to_soname’:
>> thread-db.c:652:3: error: passing argument 1 of ‘dladdr’ discards
>> ‘const’ qualifier from pointer target type [-Werror]
>> In file included from thread-db.c:33:0:
>>
>> /opt/cross/arm-linux-musleabi/lib/gcc/arm-linux-musleabi/4.7.1/../../../../arm-linux-musleabi/include/dlfcn.h:30:5:
>> note: expected ‘void *’ but argument is of type ‘const void *’
>> thread-db.c: In function ‘try_thread_db_load_from_sdir’:
>> thread-db.c:708:30: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
>> this function)
>> thread-db.c:708:30: note: each undeclared identifier is reported only
>> once for each function it appears in
>> thread-db.c: In function ‘try_thread_db_load_from_dir’:
>> thread-db.c:719:29: error: ‘LIBTHREAD_DB_SO’ undeclared (first use in
>> this function)
>> thread-db.c: In function ‘thread_db_load_search’:
>> thread-db.c:748:41: error: ‘LIBTHREAD_DB_SEARCH_PATH’ undeclared
>> (first use in this function)
>> 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

>
>
> 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.


Brian

-- 
brian
------------------

Cool-Karaoke - The smallest recording studio, in your palm, open-sourced
http://cool-idea.com.tw/

iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe

Re: Problem Compiling gdbserver with musl

[John Spencer]

On 10/21/2012 11:19 AM, Brian Wang wrote:
> On Fri, Oct 19, 2012 at 9:54 PM, John Spencer<maillist-musl@barfooze.de>  wrote:
>>
>> 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
>

gdb is supposed to be usable on multiple archs and platforms; but 
apparently they think linux == glibc; which is clearly not always the case.
the lwp_info and THREADDB stuff is used unconditionally, even though 
they checked for HAVE_THREADDB_H during configure.

it would definitely help if they get your bug report, even if it serves 
just a reminder that GNU is not alone out there.
once the critical mass of bug reports is reached, they will finally fix 
these issues.
heck, even if they removed the braindead -Werror-by-default, this would 
be a big improvement.

Re: Problem Compiling gdbserver with musl

[Rich Felker]

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

Re: Problem Compiling gdbserver with musl

[Brian Wang]

On Sun, Oct 21, 2012 at 10:24 PM, John Spencer
<maillist-musl@barfooze.de> wrote:
> On 10/21/2012 11:19 AM, Brian Wang wrote:
>>
>> On Fri, Oct 19, 2012 at 9:54 PM, John Spencer<maillist-musl@barfooze.de>
>> wrote:
>>>
>>>
>>> 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
>>
>
> gdb is supposed to be usable on multiple archs and platforms; but apparently
> they think linux == glibc; which is clearly not always the case.
> the lwp_info and THREADDB stuff is used unconditionally, even though they
> checked for HAVE_THREADDB_H during configure.
>
> it would definitely help if they get your bug report, even if it serves just
> a reminder that GNU is not alone out there.
> once the critical mass of bug reports is reached, they will finally fix
> these issues.
> heck, even if they removed the braindead -Werror-by-default, this would be a
> big improvement.

Just done filing the bug report and hope gdbserver will compile and work
with or without libthread_db in the near future. :-)


brian

-- 
brian
------------------

Cool-Karaoke - The smallest recording studio, in your palm, open-sourced
http://cool-idea.com.tw/

iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe