From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15429 invoked by alias); 11 Jun 2012 20:50:25 -0000 Received: (qmail 15410 invoked by uid 22791); 11 Jun 2012 20:50:22 -0000 X-SWARE-Spam-Status: No, hits=-5.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_BJ,TW_DW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vc0-f169.google.com (HELO mail-vc0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Jun 2012 20:49:56 +0000 Received: by vcbfl10 with SMTP id fl10so2970160vcb.0 for ; Mon, 11 Jun 2012 13:49:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=Pw4I0YhUxtPLufgeOAWqU71prjzIt3ij4EQNdwLxAQw=; b=UNpZblAadTCJakR99nnPq8Kqxh8HUQhR48I/DWs0qA3fW1KaPb7h73zH5dLPRPhuV1 tYAFOgMckK+yfJuylMPIPgW6W5m+kvCu8napmhcoaMk03y+ldP3t/3IiQZxSwOZsFCyD zWK6nPVEu+tL+F/6iZzEMrMeoANaqz81vV5TOARDhmheIHEOYnpAcleGzFvDeH3kHnlt o9Cgyl1c3NUiUORgZzgC85EU3PLV+htWgsesoXlTBACZGsglI/6/U5Q7aU70X/qUJvNw rkiPcYBOf583dgaJBhl8bk0G8FbTf6JKxqAnLIeESUxXPFzBsFPoNotmSDU5TuOvHj7P VCFw== Received: by 10.52.94.109 with SMTP id db13mr11222795vdb.4.1339447795189; Mon, 11 Jun 2012 13:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.109 with SMTP id db13mr11222785vdb.4.1339447794943; Mon, 11 Jun 2012 13:49:54 -0700 (PDT) Received: by 10.52.161.199 with HTTP; Mon, 11 Jun 2012 13:49:54 -0700 (PDT) In-Reply-To: <87d3558zcz.fsf@fleche.redhat.com> References: <87d3558zcz.fsf@fleche.redhat.com> Date: Mon, 11 Jun 2012 20:50:00 -0000 Message-ID: Subject: Re: FYI: fix latent bug in dw2_find_symbol_file From: Doug Evans To: Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkiM8DvBKH+IR4sV+FXJ1EHkrNdAQzzGjzBg+UfbktUSnEzOS4gLF1DI17oQ8eJWMw7DzzqhwWmWlawSg5DGhouDez3v8M3Rirbn0xMjUlTC5KFZOB3JnMoyaZSTwML38PptiQMVzi74Xkub7YSl1lu5uaOzQ== X-IsSubscribed: yes 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/msg00314.txt.bz2 On Mon, Jun 11, 2012 at 11:42 AM, Tom Tromey wrote: > I'm checking this in. > > dw2_find_symbol_file has a latent bug. =A0It 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. =A0The 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 =A0Tom Tromey =A0 > > =A0 =A0 =A0 =A0* dwarf2read.c (dw2_get_primary_filename_reader): New func= tion. > =A0 =A0 =A0 =A0(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, > =A0 =A0 } > =A0} > > +/* A helper function for dw2_find_symbol_file that finds the primary > + =A0 file name for a given CU. =A0This is a die_reader_func. =A0*/ > + > +static void > +dw2_get_primary_filename_reader (const struct die_reader_specs *reader, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0gdb_byte= *info_ptr, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0struct d= ie_info *comp_unit_die, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int has_= children, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0void *da= ta) > +{ > + =A0const char **result_ptr =3D data; > + =A0struct dwarf2_cu *cu =3D reader->cu; > + =A0struct attribute *attr; > + > + =A0attr =3D dwarf2_attr (comp_unit_die, DW_AT_name, cu); > + =A0if (attr =3D=3D NULL) > + =A0 =A0*result_ptr =3D NULL; > + =A0else > + =A0 =A0*result_ptr =3D DW_STRING (attr); > +} > + > =A0static const char * > =A0dw2_find_symbol_file (struct objfile *objfile, const char *name) > =A0{ > =A0 struct dwarf2_per_cu_data *per_cu; > =A0 offset_type *vec; > =A0 struct quick_file_names *file_data; > + =A0const char *filename; > > =A0 dw2_setup (objfile); > > @@ -2873,12 +2895,17 @@ dw2_find_symbol_file (struct objfile *objfile, co= nst char *name) > =A0 /* vec[0] is the length, which must always be >0. =A0*/ > =A0 per_cu =3D dw2_get_cu (MAYBE_SWAP (vec[1])); > > - =A0file_data =3D dw2_get_file_names (objfile, per_cu); > - =A0if (file_data =3D=3D NULL > - =A0 =A0 =A0|| file_data->num_file_names =3D=3D 0) > - =A0 =A0return NULL; > + =A0if (per_cu->v.quick->symtab !=3D NULL) > + =A0 =A0return per_cu->v.quick->symtab->filename; > + > + =A0if (per_cu->is_debug_types) > + =A0 =A0init_cutu_and_read_dies (per_cu, 0, 0, dw2_get_primary_filename_= reader, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&filename); > + =A0else > + =A0 =A0init_cutu_and_read_dies_simple (per_cu, dw2_get_primary_filename= _reader, > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &fi= lename); > > - =A0return file_data->file_names[file_data->num_file_names - 1]; > + =A0return filename; > =A0} > > =A0static void You need to call init_cutu_and_read_dies in both debug-types and non-debug-types cases. When DWO files are in use DW_AT_name lives in the DWO file. OTOH TUs typically don't have DW_AT_name (you need to look at DW_AT_decl_fi= le). OTOOH this function is only called by find_main_filename. So what to do? I'm tempted to rename the routine {,*_}find_function_file (or some such) and have dw2_find_symbol_file ignore TUs.