Re: Problem Compiling gdbserver with musl

[Brian Wang <brian.wang.0721@gmail.com>]

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