Date: Sun, 21 Oct 2012 17:12:17 +0800 From: Brian Wang <brian.wang.0721@...il.com> To: musl@...ts.openwall.com Subject: Re: Problem Compiling gdbserver with musl On Fri, Oct 19, 2012 at 8:30 PM, Rich Felker <dalias@...ifal.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
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.