Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: gdb-patches@sourceware.org
Subject: Re: Split DWARF and rnglists, gcc vs clang
Date: Fri, 13 Nov 2020 01:11:43 +0100	[thread overview]
Message-ID: <20201113001143.GA2654@wildebeest.org> (raw)
In-Reply-To: <d2bd55b6-67fb-a04c-95d3-bae4a0c65ff5@polymtl.ca>

Hi Simon,

On Thu, Nov 05, 2020 at 11:11:43PM -0500, Simon Marchi wrote:
> I'm currently squashing some bugs related to .debug_rnglists in GDB, and
> I happened to notice that clang and gcc do different things when
> generating rnglists with split DWARF.  I'd like to know if the two
> behaviors are acceptable, and therefore if we need to make GDB accept
> both.  Or maybe one of them is not doing things correctly and would need
> to be fixed.
> 
> clang generates a .debug_rnglists.dwo section in the .dwo file.  Any
> DW_FORM_rnglistx attribute in the DWO refers to that section.  That
> section is not shared with any other object, so DW_AT_rnglists_base is
> never involved for these attributes.  Note that there might still be a
> DW_AT_rnglists_base on the DW_TAG_skeleton_unit, in the linked file,
> used if the skeleton itself has an attribute of form DW_FORM_rnglistx.
> This rnglist would be found in a .debug_rnglists section in the linked
> file, shared with the other units of the linked file.
> 
> gcc generates a single .debug_rnglists in the linked file and no
> .debug_rnglists.dwo in the DWO files.  So when an attribute has form
> DW_FORM_rnglistx in a DWO file, I presume we need to do the lookup in
> the .debug_rnglists section in the linked file, using the
> DW_AT_rnglists_base attribute found in the corresponding skeleton unit.
> This looks vaguely similar to how it was done pre-DWARF 5, with
> DW_AT_GNU_ranges base.
> 
> So, is gcc wrong here?  I don't see anything in the DWARF 5 spec
> prohibiting to do it like gcc does, but clang's way of doing it sounds
> more in-line with the intent of what's described in the DWARF 5 spec.
> So I wonder if it's maybe an oversight or a misunderstanding between the
> two compilers.
 
I think I would have asked the question the other way around :) The
spec explicitly describes rnglists_base (and loclists_base) as a way
to reference ranges (loclists) through the index table, so that the
only relocation you need is in the (skeleton) DIE. But the rnglists
(loclists) themselves can still use relocations. A large part of them
is non-shared addresses, so using indexes (into the .debug_addr
addr_base) would simply be extra overhead. The relocations will
disappear once linked, but the index tables won't.

As an alternative, if you like to minimize the amount of debug data in
the main object file, the spec also describes how to put a whole
.debug_rnglists.dwo (or .debug_loclists.dwo) in the split dwarf
file. Then you cannot use all entry encodings and do need to use an
.debug_addr index to refer to any addresses in that case. So the
relocations are still there, you just refer to them through an extra
index indirection.

So I believe both encodings are valid according to the spec. It just
depends on what you are optimizing for, small main object file size or
smallest encoding with least number of indirections.

Cheers,

Mark

P.S. I am really interested in these interpretations of DWARF, but I
don't really follow the gdb implementation details very much. Could we
maybe move discussions like these from the -patches list to the main
gdb (or gcc) mailinglist?

  reply	other threads:[~2020-11-13  0:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-06  4:11 Simon Marchi via Gdb-patches
2020-11-13  0:11 ` Mark Wielaard [this message]
2020-11-13 14:45   ` Simon Marchi via Gdb-patches
2020-11-13 15:18     ` Mark Wielaard
2020-11-13 15:41       ` Simon Marchi via Gdb-patches
2020-11-13 18:34         ` Mark Wielaard

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=20201113001143.GA2654@wildebeest.org \
    --to=mark@klomp.org \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@polymtl.ca \
    /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