From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12482 invoked by alias); 7 Feb 2004 01:24:08 -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 12473 invoked from network); 7 Feb 2004 01:24:08 -0000 Received: from unknown (HELO saturn.billgatliff.com) (209.251.101.200) by sources.redhat.com with SMTP; 7 Feb 2004 01:24:08 -0000 Received: from billgatliff.com (bb-203-125-70-61.singnet.com.sg [203.125.70.61]) by saturn.billgatliff.com (Postfix) with ESMTP id 33C444E0004; Fri, 6 Feb 2004 19:24:06 -0600 (CST) Message-ID: <40243E3A.7040205@billgatliff.com> Date: Sat, 07 Feb 2004 01:24:00 -0000 From: Bill Gatliff User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: stepping thru assembled files that are referenced as temp files ie: /tmp/ccjirvvY.s References: <20040206235810.GA3110@nevyn.them.org> In-Reply-To: <20040206235810.GA3110@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00070.txt.bz2 Daniel: (gdb) display/i $pc (gdb) stepi (gdb) stepi ... :^( b.g. Daniel Jacobowitz wrote: >On Fri, Feb 06, 2004 at 03:49:43PM -0800, John Utz wrote: > > >>Hello; >> >>gdb 6.0 /gdbserver is telling me that i am segfaulting in a file that >>appears to be a tmp-name generated during the link process for the >>parent static library. >> >>iblit16.s is compiled into iblit16.o and ar'd into liballd_unshared.a. >>My exe is linked against liballd_unshared.a. >> >>here is what gdb says when i try to step into the problem function: >> >>(gdb) s >>_linear_clear_to_color16 () at /tmp/ccjirvvY.s:27 >>27 /tmp/ccjirvvY.s: No such file or directory >> in /tmp/ccjirvvY.s >>Current language: auto; currently asm >>(gdb) >> >>how can i tell gdb to stop looking for the tmp-name and look for this >>function in allegro-4.0.3/src/i386/iblit16.s? >> >> > >I'm guessing it's iblit16.S, or you're arranging to run it through the >C preprocessor some other way. If so, it's a known bug - no one's >thought of a good solution yet. > >You can look at the assembly code using disassemble, for what that's >worth. > > >