Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Caroline Tice <cmtice@google.com>
To: Simon Marchi <simark@simark.ca>
Cc: Caroline Tice via Gdb-patches <gdb-patches@sourceware.org>,
	Tom Tromey <tom@tromey.com>,
	Eric Christopher <echristo@google.com>
Subject: Re: [PATCH, v2] Add code for processing version 5 DWP files (for use with DWARF v5)
Date: Tue, 28 Jul 2020 12:22:00 -0700	[thread overview]
Message-ID: <CABtf2+TrvkMEgieuLUHT_DsjPjm9UQRjPG2o4ozJfX2E826kQg@mail.gmail.com> (raw)
In-Reply-To: <5e77197d-dbb3-5718-bfe8-e263c4006a06@simark.ca>

[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]

On Wed, Jul 22, 2020 at 6:04 AM Simon Marchi <simark@simark.ca> wrote:

> On 2020-07-21 12:06 a.m., Caroline Tice wrote:
> > The DWARF v5 Spec describes a (slightly) new format for V5 .dwp files.
> > This patch updates GDB to allow it to read/process .dwp files in the
> > new DWARF v5 format, while continuing to be able to read/process .dwp
> > files in the older V1 & V2 formats.
>
> Can you please describe in the commit message what those differences are?
>
>
Done.


> > The one thing I felt a little odd about in this patch:  I couldn't
> > re-use the enum dwarf_sect
> > definitions, because  in version 5 several of the sections have the
> > same name as in the previous versions, but have a different ordering,
> > with different numbers attached.  So I had to create a new enum,
> > dwarf_sect_v5 for this purpose.
>
> That part would need to be cross-posted to the binutils mailing list.
> binutils
> does use the DW_SECT_* enumerators, presumably to read dwp files too, so
> they
> would likely use those new DWARF 5 enumerators eventually.
>
>
I will create/submit a patch to the binutils mailing list.


> > Is this patch ok to commit?
>
> It would be useful to precise somewhere, perhaps in the comment on `struct
> dwp_sections`.
> that versions 1 and 2 are pre-standard versions, and that version 5 was
> introduced in
> DWARF5.  And that versions 3 and 4 don't exist.
>

Done.


>
> I don't have time to do an in-depth review right now, but one question
> that came to mind
> is: is an advantage of having virtual_v2_or_v5_dwo_sections over having
> separate
> virtual_v2_dwo_sections and virtual_v5_dwo_sections?


Not particularly; I was just trying to avoid code duplication.


> Now when using v2 or v5, there are
> fields you don't use (because they are either v2-specific or v5-specific),
> so I imagine
> it's just more error prone.  Does it avoid a lot of code duplication?
>

A small amount, but not a lot.


>
> Simon
>

Below is my updated patch (mostly just updated comments & commit message)

[-- Attachment #2: v2-0001-Add-code-for-processing-version-5-DWP-files-for-u.patch --]
[-- Type: application/x-patch, Size: 30789 bytes --]

  reply	other threads:[~2020-07-28 19:22 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-21  4:06 [PATCH, v1] " Caroline Tice
2020-07-22 13:04 ` Simon Marchi
2020-07-28 19:22   ` Caroline Tice [this message]
2020-07-29 21:05     ` [PATCH, v3] " Caroline Tice
2020-08-05 15:57       ` Caroline Tice
2020-08-05 20:14       ` Tom Tromey
2020-08-06 17:58         ` [PATCH, v4] " Caroline Tice
2020-08-06 19:25           ` Tom Tromey

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=CABtf2+TrvkMEgieuLUHT_DsjPjm9UQRjPG2o4ozJfX2E826kQg@mail.gmail.com \
    --to=cmtice@google.com \
    --cc=echristo@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    --cc=tom@tromey.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