From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36580 invoked by alias); 19 Sep 2017 19:58:51 -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 35889 invoked by uid 89); 19 Sep 2017 19:58:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-21.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=limp, H*c:alternative, Technically, HX-Envelope-From:sk:alexand X-HELO: mail-vk0-f54.google.com Received: from mail-vk0-f54.google.com (HELO mail-vk0-f54.google.com) (209.85.213.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Sep 2017 19:58:49 +0000 Received: by mail-vk0-f54.google.com with SMTP id z187so372384vkd.13 for ; Tue, 19 Sep 2017 12:58:48 -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:from:date:message-id:subject:to; bh=T+MtaJ54HMNu6GNrdsX7+HKcnjMEUOV7cmrgyMQPG1k=; b=qieTILWNzR/Ts1MKmH8cPHG7TEbe2uBH7q/o+ecbHVRwXTQppD0YHDtQzxGXxgj+5g LE//bdc90Rgmt/lPeYhFXDNaWpot/PbWijlcBUrngoLznMCxSJFdhg4ENfdb1MBQI5tA n4wC8xEx76uYkZuiT5dpbv7oHFMbci1nCQoFiQb7NhLyUy6xy6Q5ENiXg4txSsK5cEGg ax3FFTP+9La/DC1XcRMrj4c7YJ/rX0xnntMEng/Rqd5thfpJsjDtLvVo9aR6ClcMGJWf i6d4d4nUHv11m85Ul9kXDGkpy6Vp21lViNNlykRvtY+LUiomsOiokMsRbv7tq/qqDqMc b5nA== X-Gm-Message-State: AHPjjUgGqT8Nx7cluKCOAJjumuaAyuTCZSE9IxCEqjkE5Vz9VWdUqw8K waKqDLlnxOJkkdc3RO2nXJerY8V3zDgJYnvnFvQC07gD X-Google-Smtp-Source: AOwi7QCiij30JiwHyZGAwtpqmKA1+283mB3Arbxf2R50UIJA5CYxHAI9RrDtMvtXHN5SkwKEE6Qnl1hQsknDDgOWEVA= X-Received: by 10.31.169.2 with SMTP id s2mr1982443vke.86.1505851127163; Tue, 19 Sep 2017 12:58:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.50.193 with HTTP; Tue, 19 Sep 2017 12:58:46 -0700 (PDT) From: Alexander Shaposhnikov Date: Tue, 19 Sep 2017 19:58:00 -0000 Message-ID: Subject: [PATCH] Fix reading .dwp files without .debug_tu_index To: gdb-patches@sourceware.org Content-Type: multipart/alternative; boundary="001a1142578484ed5e055990493a" X-SW-Source: 2017-09/txt/msg00470.txt.bz2 --001a1142578484ed5e055990493a Content-Type: text/plain; charset="UTF-8" Content-length: 2653 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, 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; if (dwp_file->version == 2) bfd_map_over_sections (dwp_file->dbfd, dwarf2_locate_v2_dwp_sections, Kind regards, Alexander Shaposhnikov --001a1142578484ed5e055990493a--