From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32386 invoked by alias); 23 Feb 2004 19:11:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32379 invoked from network); 23 Feb 2004 19:11:04 -0000 Received: from unknown (HELO necron.inter.net.il) (192.114.186.21) by sources.redhat.com with SMTP; 23 Feb 2004 19:11:04 -0000 Received: from zaretski (pns03-195-176.inter.net.il [80.230.195.176]) by necron.inter.net.il (MOS 3.4.4-GR) with ESMTP id ADS93136; Mon, 23 Feb 2004 09:09:33 GMT Date: Mon, 23 Feb 2004 19:11:00 -0000 From: "Eli Zaretskii" To: Elena Zannoni Message-Id: <6013-Mon23Feb2004211008+0200-eliz@elta.co.il> CC: gdb-patches@sources.redhat.com In-reply-to: <16442.6037.378665.429220@localhost.redhat.com> (message from Elena Zannoni on Mon, 23 Feb 2004 10:09:09 -0500) Subject: Re: [RFA] Fix a crash in coffread.c (Was: GDB 6.1 branch 2004-02-26-gmt) Reply-to: Eli Zaretskii References: <20040220011823.848FD4B104@berman.michael-chastain.com> <9791-Sat21Feb2004181440+0200-eliz@elta.co.il> <3099-Sun22Feb2004230710+0200-eliz@elta.co.il> <16442.6037.378665.429220@localhost.redhat.com> X-SW-Source: 2004-02/txt/msg00647.txt.bz2 > From: Elena Zannoni > Date: Mon, 23 Feb 2004 10:09:09 -0500 > > > + /* If the line number is full (e.g. 64K lines in COFF debug info), > ^^^^^^^^ > table? Yes, a typo. Thanks for catching it. > how about a while loop? Consider it done. > I am not sure I understand how the two cases differ in the layout of > the debug info. Sorry, I don't understand: what two cases? > Is the beginning of a function still zero valued? AFAIU, the code tested for the zero-valued L_LNNO32 (&lptr) too late: the call to bfd_coff_swap_lineno_in is before the test, and it's that call that caused GDB to crash, since rawptr ran out of the valid address space. > Do we have a function with >64k lines? No, the entire program totals more than 64k lines. > If we are running beyond the end of the table, does this mean that > we don't read all the debug info we have? We do read all the available info. GNU ld stops writing the table when it has more than 64k lines (and prints a warning to that effect). In the cases I debugged, the line table was allocated for precisely 64k lines, a clear sign that the table overflowed during linking (I also saw the warning). Since no more info about line numbers is available, we don't lose anything. AFAIK, the rest of the debug info, i.e. the symbol table, is still being read, we just lose information about source line to code association for some of the functions. The reason for running beyond the end of the table is, AFAIU, that the test to terminate the loop is not good enough to catch the end of the table in time, at least in the case I debugged. I don't really understand how it was supposed to make sure that dereferencing rawptr in libbfd.c:bfd_getl32 (called from bfd_coff_swap_lineno_in) will not segfault, without an explicit test of rawptr's value; do you?