From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30193 invoked by alias); 23 Jun 2005 17:06:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 30110 invoked by uid 22791); 23 Jun 2005 17:06:26 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 23 Jun 2005 17:06:26 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j5NH6PXk019842 for ; Thu, 23 Jun 2005 13:06:25 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j5NH6Ou21855 for ; Thu, 23 Jun 2005 13:06:24 -0400 Received: from calimero.vinschen.de (vpn50-40.rdu.redhat.com [172.16.50.40]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j5NH6MWM016733 for ; Thu, 23 Jun 2005 13:06:23 -0400 Received: by calimero.vinschen.de (Postfix, from userid 500) id 595BE544122; Thu, 23 Jun 2005 19:06:26 +0200 (CEST) Date: Thu, 23 Jun 2005 17:06:00 -0000 From: Corinna Vinschen To: gdb@sources.redhat.com Subject: Further cache generating if PC is 0? Message-ID: <20050623170626.GT2814@calimero.vinschen.de> Reply-To: gdb@sources.redhat.com Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-SW-Source: 2005-06/txt/msg00209.txt.bz2 I don't know if the subject is clear enough, but here we go. While debugging, I came across the following situation. It happened on i686-pc-linux-gnu, but it's not exactly an ix86 problem. The idea is, how does a backtrace look like, if symbol information is missing? For that purpose, just start any application using share libs and disallow loading solib symbols: (gdb) set auto-solib-add no (gdb) set backtrace past-main (gdb) br main Breakpoint 1 at 0x8048465: file x.c, line 82. (gdb) r Starting program: /home/corinna/useless-test-app Breakpoint 1, main (argc=1, argv=0xffffbf54) at x.c:82 82 func_1 (1); (gdb) bt #0 main (argc=1, argv=0xffffbf54) at x.c:82 #1 0x55595b10 in ?? () from /lib/tls/libc.so.6 #2 0x00000001 in ?? () #3 0xffffbf54 in ?? () #4 0xffffbf5c in ?? () #5 0x5556cdf8 in ?? () #6 0x55692ff4 in ?? () from /lib/tls/libc.so.6 #7 0x5556bcc0 in ?? () from /lib/ld-linux.so.2 #8 0x08048480 in main () #9 0x080482c1 in _start () at start.S:119 (gdb) Oh well, that doesn't look good. Now, how *should* it look like: (gdb) sharedlibrary c Loaded symbols for /lib/tls/libc.so.6 (gdb) bt #0 main (argc=1, argv=0xffffbf54) at x.c:82 #1 0x55595b10 in __libc_start_main () from /lib/tls/libc.so.6 #2 0x080482c1 in _start () at start.S:119 (gdb) So the question was, why does the backtrace look so broken when the symbol information is missing? It turned out that this is a result of not being able to retrieve the function start address in the i386_frame_cache function. Many (most?) target_frame_cache function are doing pretty much the same, just differing in details. Generally, they do something like this: [...] cache->base = frame_unwind_register_unsigned (next_frame, FP_regnum); if (cache->base == 0) return cache; cache->pc = frame_func_unwind (next_frame); if (cache->pc != 0) analyze_prologue (); if (we_dont_know_the_frame_layout || frameless_function) cache->base = frame_unwind_register_unsigned (next_frame, SP_regnum) + some_offset; cache->saved_sp = cache->base + some_other_offset; [...] What goes wrong in the above example is that frame_func_unwind returns 0. There's no PC to retrieve since no information about the shared library is given due to switching off auto-solib-add. Since we don't have a function address, we can't analyze the prologue. Since the prologue analyzis determines our knowledge about the frame layout, but it hasn't been called, we don't trust the value of the unwinded frame pointer. Ok, so we unwind the stack pointer and what happens at that point is a pretty hopeless guess. The guess is that the function is frameless and has either no local variables or we're still in the prologue. So the obvious question is this: If frame_func_unwind returns 0, isn't proceeding useless and shouldn't the frame_cache function return 0 in cache->base and return? Perhaps together with a warning message that the backtrace would become unreliable if we proceed? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc.