From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9154 Path: news.gmane.org!not-for-mail From: Felix Fietkau Newsgroups: gmane.linux.lib.musl.general Subject: Re: MUSCL + MIPS + threads + debugging/stack traces Date: Tue, 19 Jan 2016 13:45:31 +0100 Message-ID: <569E2FEB.3090305@openwrt.org> References: <20160119041950.GO238@brightrain.aerifal.cx> 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: 7bit X-Trace: ger.gmane.org 1453207552 19310 80.91.229.3 (19 Jan 2016 12:45:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2016 12:45:52 +0000 (UTC) Cc: musl@wardco.com To: musl@lists.openwall.com Original-X-From: musl-return-9167-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 19 13:45:51 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aLVfT-0004O9-5m for gllmg-musl@m.gmane.org; Tue, 19 Jan 2016 13:45:51 +0100 Original-Received: (qmail 30540 invoked by uid 550); 19 Jan 2016 12:45:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30522 invoked from network); 19 Jan 2016 12:45:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on arrakis.dune.hu X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Virus-Scanned: at arrakis.dune.hu User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <20160119041950.GO238@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:9154 Archived-At: On 2016-01-19 05:19, Rich Felker wrote: > On Mon, Jan 18, 2016 at 05:34:27PM -0800, Ward Willats wrote: >> Hello. >> >> We're working on a consumer product using an OpenWRT-based MIPS >> Linux platform and linking our C++11 std::thread (really pthread) >> app to MUSL. >> >> When we try to get a backtrace with the toolchain gdb/gdbserver (or >> the latest one we cross compiled ourselves from source) we get these >> kind of pathetic, truncated stack traces. >> >> Here, for example, is a sample: >> >> (gdb) thread apply all backtrace >> >> Thread 4 (Thread 8009.9567): >> #0 0x77fcb904 in __cp_end () from /Volumes/OpenWrt/fsp-openwrt/staging_dir/target-mipsel_24kec+dsp_musl-1.1.11/root-UberFSP/lib/ld-musl-mipsel-sf.so.1 >> #1 0x77fc6f38 in __syscall_cp_c () from /Volumes/OpenWrt/fsp-openwrt/staging_dir/target-mipsel_24kec+dsp_musl-1.1.11/root-UberFSP/lib/ld-musl-mipsel-sf.so.1 >> #2 0x00000000 in ?? () >> Backtrace stopped: frame did not save the PC >> >> Thread 3 (Thread 8009.9566): >> #0 0x77fcb904 in __cp_end () from /Volumes/OpenWrt/fsp-openwrt/staging_dir/target-mipsel_24kec+dsp_musl-1.1.11/root-UberFSP/lib/ld-musl-mipsel-sf.so.1 >> #1 0x77fc6f38 in __syscall_cp_c () from /Volumes/OpenWrt/fsp-openwrt/staging_dir/target-mipsel_24kec+dsp_musl-1.1.11/root-UberFSP/lib/ld-musl-mipsel-sf.so.1 >> #2 0x00000000 in ?? () >> Backtrace stopped: frame did not save the PC >> >> Thread 2 (Thread 8009.9565): >> #0 0x77fcb904 in __cp_end () from /Volumes/OpenWrt/fsp-openwrt/staging_dir/target-mipsel_24kec+dsp_musl-1.1.11/root-UberFSP/lib/ld-musl-mipsel-sf.so.1 >> #1 0x77fc6f38 in __syscall_cp_c () from /Volumes/OpenWrt/fsp-openwrt/staging_dir/target-mipsel_24kec+dsp_musl-1.1.11/root-UberFSP/lib/ld-musl-mipsel-sf.so.1 >> warning: GDB can't find the start of the function at 0x77b8da46. >> >> GDB is unable to find the start of the function at 0x77b8da46 >> and thus can't determine the size of that function's stack frame. >> This means that GDB may be unable to access that stack frame, or >> the frames below it. >> This problem is most likely caused by an invalid program counter or >> stack pointer. >> However, if you think GDB should simply search farther back >> from 0x77b8da46 for code which looks like the beginning of a >> function, you can increase the range of the search using the `set >> heuristic-fence-post' command. >> #2 0x77b8da48 in ?? () > > It looks like your libc build lacks debug info and thus gdb is > attempting to use heuristics to make sense of the call stack. Do you > know if this is the case, and if so, whether there's a way to get > OpenWRT to build libc with -g? It's also possible that missing CFI in > our asm files it the cause. I'll ask and see if anyone else familiar > with MIPS has run into this and has ideas. Seems that I forgot to put in --enable-debug in the Makefile. This is fixed in r48363 now. - Felix