Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Alexander Shaposhnikov <alexander.v.shaposhnikov@gmail.com>
To: gdb-patches@sourceware.org, dje@google.com, palves@redhat.com
Subject: Re: [PATCH] Fix reading .dwp files without .debug_tu_index
Date: Sun, 24 Sep 2017 23:37:00 -0000	[thread overview]
Message-ID: <CAFG51+mrDfTcx5i+7Hj-nzTPv8ija+SQADNdRcEmwuhWhmRZkQ@mail.gmail.com> (raw)
In-Reply-To: <CAFG51+=MhmN13if6jPHBJqh95_G5oxzYG26ZvcjgmHA0H=VTTw@mail.gmail.com>

cc: Doug Evans, Pedro Alves
Kind regards,
Alexander Shaposhnikov

On Tue, Sep 19, 2017 at 12:58 PM, Alexander Shaposhnikov <
alexander.v.shaposhnikov@gmail.com> 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, 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 <alexander.v.shaposhnikov@gmail.com>
>
> * 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
>


  reply	other threads:[~2017-09-24 23:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-19 19:58 Alexander Shaposhnikov
2017-09-24 23:37 ` Alexander Shaposhnikov [this message]
2017-09-26  3:15 ` Doug Evans via gdb-patches
2017-09-26  4:13   ` Alexander Shaposhnikov
2017-09-26 17:51     ` Doug Evans via gdb-patches
2017-09-26 18:48       ` Alexander Shaposhnikov
2017-09-28 16:30 Doug Evans via gdb-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFG51+mrDfTcx5i+7Hj-nzTPv8ija+SQADNdRcEmwuhWhmRZkQ@mail.gmail.com \
    --to=alexander.v.shaposhnikov@gmail.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox