From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2543 invoked by alias); 23 Feb 2004 21:01:43 -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 2481 invoked from network); 23 Feb 2004 21:01:41 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 23 Feb 2004 21:01:41 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id 2F9711A448A; Mon, 23 Feb 2004 15:57:02 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16442.26910.87173.36717@localhost.redhat.com> Date: Mon, 23 Feb 2004 21:01:00 -0000 To: Eli Zaretskii Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [RFA] Fix a crash in coffread.c (Was: GDB 6.1 branch 2004-02-26-gmt) In-Reply-To: <6013-Mon23Feb2004211008+0200-eliz@elta.co.il> 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> <6013-Mon23Feb2004211008+0200-eliz@elta.co.il> X-SW-Source: 2004-02/txt/msg00658.txt.bz2 Eli Zaretskii writes: > > 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? with and w/o the max reached. You explain below. > > > 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. > ah, right. > > Do we have a function with >64k lines? > > No, the entire program totals more than 64k lines. > ok, I am not too familiar with the layout. I guess there is a big table with 0 entries to mark functions. > > 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. > ah, ok. I was wondering at what stage the information was lost. We don't have to worry about it then. > 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? No, probably it was one of those "it will never happen" things. I've seen those assumptions before... Ok, then, check it in. elena