From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66346 invoked by alias); 26 Sep 2017 04:13:34 -0000 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 Received: (qmail 64571 invoked by uid 89); 26 Sep 2017 04:13:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-21.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:alternative X-HELO: mail-ua0-f178.google.com Received: from mail-ua0-f178.google.com (HELO mail-ua0-f178.google.com) (209.85.217.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Sep 2017 04:13:32 +0000 Received: by mail-ua0-f178.google.com with SMTP id t36so5658299uah.10 for ; Mon, 25 Sep 2017 21:13:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tGv5k05CseeKbEfeOgPjg0v+3mX8Gl3BVJvGkZyIKf8=; b=j4Mlbd6wwl/+ZI5/QPCREco9RHRD5yGZbhIilQRaRUvq/0K7vlZP6gtznp1ybZqdYg FCTih4mdod3++0qSNMJG26GikWSuW5yPUG9izFuSRxoZk6S4KxG3crmT75eoapL6Upur EvZ8QRNotOAzYRGWAIBrL6b7uNGkv5hOl7zTpP/sMPwjUbHbc6LCQM5lSW49oWBJR1gq LdYwuQfsCU51y6duvO2oumHyPNEtRF4ek+KFbw+afoGmDix0UYn1kUvxo/IECHA/KaMe ECpjnVnuEeDgSL2M4AuTOjhT24TCQwGLQprvnAGDkyLiu93iaJ0jnVRqRb6boLDYg2YP gjsA== X-Gm-Message-State: AHPjjUgHdpcEidi/LfbrQDdQqG76GOlgALZ5jgBFzE9tlJ0H7djOddWQ X9SEnLaCEHUApZclAnFuAZbz5sle377MHeOkG46+NuZ/ X-Google-Smtp-Source: AOwi7QDOsmNfMZK6eTLpk37WS5M0QtYyxY5PG1wtyRvCTCzUjTI6moIWE30sD6j6Hi9jVW+QdNPzYYldfa/X0dcyyM4= X-Received: by 10.176.1.66 with SMTP id 60mr9798024uak.48.1506399210507; Mon, 25 Sep 2017 21:13:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.50.193 with HTTP; Mon, 25 Sep 2017 21:13:30 -0700 (PDT) In-Reply-To: References: From: Alexander Shaposhnikov Date: Tue, 26 Sep 2017 04:13:00 -0000 Message-ID: Subject: Re: [PATCH] Fix reading .dwp files without .debug_tu_index To: Doug Evans Cc: gdb-patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-09/txt/msg00781.txt.bz2 >I'd go with something like (untested and likely improperly formatted): >if (dwp_file->cus) > dwp_file->version = dwp_file-cus->version; > else if (dwp_file->tus) > dwp_file->version = dwp_file->tus->version > else > dwp_file->version = 2; i'm ok with that change, many thanks, do i need to resend the patch ? (and yeah, i can double check / test it when i get home) regarding the dependence on the order of sections - (if i am not mistaken) yeah, it's a separate issue - i can provide more details when i get to my laptop. Best regards, Alexander Shaposhnikov On Mon, Sep 25, 2017 at 8:14 PM, Doug Evans wrote: > On Tue, Sep 19, 2017 at 12:58 PM, Alexander Shaposhnikov > wrote: > > This patch fixes segmentation fault (due to dereferencing of a null > pointer) > > in dwarf2read.c in the code dwp_file->cus->version != > dwp_file->tus->version > > by adding defensive checks similarly to how it's already done > > at the lines 11208 - 11215 (in the same file dwarf2read.c). > > The issue can be reproduced with dwp packages built by llvm-dwp utility > > (from the current upstream) since at the moment llvm-dwp doesn't create > > .debug_tu_index section, thus dwp_file->tus will be null. > > > > Test plan: > > > > BUILD: > > main.cpp: > > int f() { > > int x = 0; > > int y = 1; > > return x + y; > > } > > g++ -fPIC -gsplit-dwarf -g -O0 main.cpp -o main.exe > > llvm-dwp main.dwo -o main.exe.dwp > > # This step is a workaround to a separate issue (unrelated to this > patch). > > # At the moment llvm tools & clang put .strtab section first (its index > is > > 1), > > # while gcc/gold/binutils put it at the end. > > # Unfortunately gdb (in the code reading dwps) appears to depend on the > > order > > # of sections, > > That's odd. Depends on the order of sections how? > > > to workaround this (to reproduce the issue which this patch > > # aims to address) we use objcopy to do the following trick: > > # if one asks to remove .strtab objcopy will do that but at the same time > > # it will create a new .shstrtab section at the end. > > objcopy --remove-section .strtab main.exe.dwp > > RUN: > > gdb main.exe > > One can observe that now there is no crash and debugging functionality > > works as expected (setting breakpoints, printing local variable, > exploring > > the stack). > > > > gdb/ChangeLog: > > yyyy-mm-dd Alexander Shaposhnikov > > > > * dwarf2read.c: Fix segmentation fault on reading > > > > .dwp files without .debug_tu_index section. > > > > Patch: > > > > diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c > > > > index b1914cf876..547e3f034e 100644 > > --- a/gdb/dwarf2read.c > > +++ b/gdb/dwarf2read.c > > @@ -11185,7 +11185,8 @@ open_and_init_dwp_file (void) > > dwp_file->tus = create_dwp_hash_table (dwp_file, 1); > > > > /* The DWP file version is stored in the hash table. Oh well. */ > > - if (dwp_file->cus->version != dwp_file->tus->version) > > + if (dwp_file->cus && dwp_file->tus > > + && dwp_file->cus->version != dwp_file->tus->version) > > { > > /* Technically speaking, we should try to limp along, but this is > > pretty bizarre. We use pulongest here because that's the > established > > @@ -11195,7 +11196,7 @@ open_and_init_dwp_file (void) > > pulongest (dwp_file->cus->version), > > pulongest (dwp_file->tus->version), dwp_name.c_str ()); > > } > > - dwp_file->version = dwp_file->cus->version; > > + dwp_file->version = dwp_file->cus ? dwp_file->cus->version : 0; > > A version of 0 doesn't seem right. > I'd go with something like (untested and likely improperly formatted): > > if (dwp_file->cus) > dwp_file->version = dwp_file-cus->version; > else if (dwp_file->tus) > dwp_file->version = dwp_file->tus->version > else > dwp_file->version = 2; > > ok with that change. > > > > > if (dwp_file->version == 2) > > bfd_map_over_sections (dwp_file->dbfd, > dwarf2_locate_v2_dwp_sections, > > > > > > Kind regards, > > Alexander Shaposhnikov >