From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2182 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Problem Compiling gdbserver with musl Date: Sun, 21 Oct 2012 10:32:46 -0400 Message-ID: <20121021143246.GA254@brightrain.aerifal.cx> References: <50815B8A.3070109@barfooze.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1350830493 12260 80.91.229.3 (21 Oct 2012 14:41:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Oct 2012 14:41:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2183-gllmg-musl=m.gmane.org@lists.openwall.com Sun Oct 21 16:41:40 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TPwih-0008Tq-2k for gllmg-musl@plane.gmane.org; Sun, 21 Oct 2012 16:41:39 +0200 Original-Received: (qmail 3910 invoked by uid 550); 21 Oct 2012 14:41:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3899 invoked from network); 21 Oct 2012 14:41:30 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2182 Archived-At: 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