From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16185 invoked by alias); 11 Jun 2012 18:42:22 -0000 Received: (qmail 16173 invoked by uid 22791); 11 Jun 2012 18:42:21 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_BJ,TW_DW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jun 2012 18:42:06 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5BIg6Ai003565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Jun 2012 14:42:06 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5BIg4tm026304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 11 Jun 2012 14:42:05 -0400 From: Tom Tromey To: gdb-patches@sourceware.org Subject: FYI: fix latent bug in dw2_find_symbol_file Date: Mon, 11 Jun 2012 18:42:00 -0000 Message-ID: <87d3558zcz.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-06/txt/msg00304.txt.bz2 I'm checking this in. dw2_find_symbol_file has a latent bug. It assumes that the last file in file name table is the primary file name for the CU. However, there's no reason this must be true. The primary file name could appear anywhere. And, since this method returns just the file name, and not the directory name, there is no reason to even bother reading the line number program -- we can just use the CU DIE's DW_AT_name. I don't have a test case for this; but the situation came up with the dwz multifile code. Built and regtested on x86-64 Fedora 16. Tom 2012-06-11 Tom Tromey * dwarf2read.c (dw2_get_primary_filename_reader): New function. (dw2_find_symbol_file): Use it. diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c index 589361e..7e25d08 100644 --- a/gdb/dwarf2read.c +++ b/gdb/dwarf2read.c @@ -2836,12 +2836,34 @@ dw2_expand_symtabs_with_filename (struct objfile *objfile, } } +/* A helper function for dw2_find_symbol_file that finds the primary + file name for a given CU. This is a die_reader_func. */ + +static void +dw2_get_primary_filename_reader (const struct die_reader_specs *reader, + gdb_byte *info_ptr, + struct die_info *comp_unit_die, + int has_children, + void *data) +{ + const char **result_ptr = data; + struct dwarf2_cu *cu = reader->cu; + struct attribute *attr; + + attr = dwarf2_attr (comp_unit_die, DW_AT_name, cu); + if (attr == NULL) + *result_ptr = NULL; + else + *result_ptr = DW_STRING (attr); +} + static const char * dw2_find_symbol_file (struct objfile *objfile, const char *name) { struct dwarf2_per_cu_data *per_cu; offset_type *vec; struct quick_file_names *file_data; + const char *filename; dw2_setup (objfile); @@ -2873,12 +2895,17 @@ dw2_find_symbol_file (struct objfile *objfile, const char *name) /* vec[0] is the length, which must always be >0. */ per_cu = dw2_get_cu (MAYBE_SWAP (vec[1])); - file_data = dw2_get_file_names (objfile, per_cu); - if (file_data == NULL - || file_data->num_file_names == 0) - return NULL; + if (per_cu->v.quick->symtab != NULL) + return per_cu->v.quick->symtab->filename; + + if (per_cu->is_debug_types) + init_cutu_and_read_dies (per_cu, 0, 0, dw2_get_primary_filename_reader, + &filename); + else + init_cutu_and_read_dies_simple (per_cu, dw2_get_primary_filename_reader, + &filename); - return file_data->file_names[file_data->num_file_names - 1]; + return filename; } static void