From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24601 invoked by alias); 20 Aug 2002 21:59:15 -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 24594 invoked from network); 20 Aug 2002 21:59:13 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 20 Aug 2002 21:59:13 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g7KLmWG08128; Tue, 20 Aug 2002 16:48:32 -0500 To: Joel Brobecker CC: gdb-patches@sources.redhat.com Subject: [Jim Blandy ] Re: RFA: don't read coff line number unless we have symbols too From: Jim Blandy Date: Tue, 20 Aug 2002 14:59:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SW-Source: 2002-08/txt/msg00620.txt.bz2 --=-=-= Content-length: 1386 Joel, you said this patch caused you some problems, and asked me to put it on hold until you had more data. Can you verify that this does indeed break something? I'm pretty confident that you were observing something else. I'm skeptical that it causes problems because the patch (as I understand it, anyway) simply prevents GDB from reading data it will never use. The logic goes like this: If num_symbols > 0, then GDB behaves exactly as before. This is easy to see. If num_symbols is zero, then: a) GDB does not call bfd_map_over_sections with find_linenos as its working function. find_linenos's only side effect is to set info->{min,max}_lineno_offset. So those are left zero. b) We don't register free_linetab_cleanup. c) We don't call init_lineno. That function's only side effect is to set linetab{,_offset,_size}. Since this is the only place the table is ever allocated, b) has no effect. And this call is the only use of info->{min,max}_lineno_offset, so we know that a) has no effect. d) We pass zero as coff_symtab_read's second argument, nsyms. This is just what GDB would do without the patch, so this can't break anything new. But when nsyms is zero, we never enter coff_symtab_read's main while loop, so enter_linenos never gets called. That function is the only use of linetab{,_offset,_size}, so c) has no effect. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-length: 5505 X-From-Line: jimb@redhat.com Sun Jun 26 13:22:51 2002 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id LAA01648 for ; Wed, 26 Jun 2002 11:23:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with SMTP id g5QINBd10213 for ; Wed, 26 Jun 2002 14:23:11 -0400 Received: from sources.redhat.com (sources.redhat.com [209.249.29.67]) by mx1.redhat.com (8.11.6/8.11.6) with SMTP id g5QIDg915324 for ; Wed, 26 Jun 2002 14:13:42 -0400 Received: (qmail 31663 invoked by alias); 26 Jun 2002 18:22:57 -0000 Received: (qmail 31607 invoked from network); 26 Jun 2002 18:22:53 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 26 Jun 2002 18:22:53 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 8A45A5EA11; Wed, 26 Jun 2002 13:22:51 -0500 (EST) Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Delivered-To: mailing list gdb-patches@sources.redhat.com To: "Philippe De Muyter" Cc: Joel Brobecker , gdb-patches@sources.redhat.com Subject: Re: RFA: don't read coff line number unless we have symbols too References: <200206260803.g5Q83f028100@mail.macqel.be> From: Jim Blandy Date: 26 Jun 2002 13:22:51 -0500 In-Reply-To: <200206260803.g5Q83f028100@mail.macqel.be> Gnus-Warning: This is a duplicate of message Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 X-Content-Length: 3217 Status: Content-length: 3218 Lines: 86 Xref: zwingli.cygnus.com mail.gdb.patches:17199 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii "Philippe De Muyter" writes: > Should the following lines not be kept outside of the conditional block ? > > info->min_lineno_offset = 0; > info->max_lineno_offset = 0; Sure, those can be moved outside. I was just thinking of those as just establishing the pre-condition for the loop that bfd_map_over_sections does. Those fields are never used outside the "read the line number table" block, and the worker function for bfd_map_over_sections --- effectively, the loop body. In that light, it makes more sense to keep them right next to the call, as they are in the original code. Here's a revised patch, if you prefer the initializations outside. 2002-03-06 Jim Blandy * coffread.c (coff_symfile_read): Don't try to read the line number table from disk if the image file doesn't have a symbol table; we'll never actually look at the info anyway, and Windows ships DLL's with bogus file offsets for the line number data. Index: gdb/coffread.c =================================================================== RCS file: /cvs/src/src/gdb/coffread.c,v retrieving revision 1.26 diff -c -r1.26 coffread.c *** gdb/coffread.c 19 Mar 2002 19:00:03 -0000 1.26 --- gdb/coffread.c 26 Jun 2002 18:19:07 -0000 *************** *** 593,608 **** /* End of warning */ - /* Read the line number table, all at once. */ info->min_lineno_offset = 0; info->max_lineno_offset = 0; - bfd_map_over_sections (abfd, find_linenos, (void *) info); ! make_cleanup (free_linetab_cleanup, 0 /*ignore*/); ! val = init_lineno (abfd, info->min_lineno_offset, ! info->max_lineno_offset - info->min_lineno_offset); ! if (val < 0) ! error ("\"%s\": error reading line numbers\n", name); /* Now read the string table, all at once. */ --- 593,626 ---- /* End of warning */ info->min_lineno_offset = 0; info->max_lineno_offset = 0; ! /* Only read line number information if we have symbols. ! ! On Windows NT, some of the system's DLL's have sections with ! PointerToLinenumbers fields that are non-zero, but point at ! random places within the image file. (In the case I found, ! KERNEL32.DLL's .text section has a line number info pointer that ! points into the middle of the string `lib\\i386\kernel32.dll'.) ! ! However, these DLL's also have no symbols. The line number ! tables are meaningless without symbols. And in fact, GDB never ! uses the line number information unless there are symbols. So we ! can avoid spurious error messages (and maybe run a little ! faster!) by not even reading the line number table unless we have ! symbols. */ ! if (num_symbols > 0) ! { ! /* Read the line number table, all at once. */ ! bfd_map_over_sections (abfd, find_linenos, (void *) info); ! ! make_cleanup (free_linetab_cleanup, 0 /*ignore*/); ! val = init_lineno (abfd, info->min_lineno_offset, ! info->max_lineno_offset - info->min_lineno_offset); ! if (val < 0) ! error ("\"%s\": error reading line numbers\n", name); ! } /* Now read the string table, all at once. */ --=-=-=--