public inbox for
 help / color / mirror / Atom feed
From: Mark Wielaard <>
To: Tom de Vries <>
Subject: Re: [PATCH] Fix .debug_line reference above end of section
Date: Thu, 4 Mar 2021 01:33:57 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210302135713.GA22526@delia>

Hi Tom,

On Tue, Mar 02, 2021 at 02:57:14PM +0100, Tom de Vries wrote:
> Consider the file test-import-repeatedly from PR26738, combined with a trivial
> a.out:
> ...
> $ cp test-import-repeatedly 1
> $ gcc -m32 -g ~/hello.c
> $ cp a.out 2
> ...
> When doing multifile optimization, we run into:
> ...
> $ dwz -m 3 2 1
> dwz: 3: .debug_line reference above end of section
> ...
> Using --devel-save-temps and src/contrib/ we get the
> unoptimized multifile, and find there a CU:
> ...
>   Compilation Unit @ offset 0x371:
>    Length:        0x6d (32-bit)
>    Version:       4
>    Abbrev Offset: 0x14d
>    Pointer Size:  4
>  <0><37c>: Abbrev Number: 1 (DW_TAG_compile_unit)
>     <37d>   DW_AT_stmt_list   : 0xda
>     <381>   DW_AT_language    : 0       (Unknown: 0)
>     <382>   DW_AT_comp_dir    : ./build-3.8
> ...
> which refers to a .debug_line offset 0xda, but the debug_line section only
> contains an entry at offset 0x0.

I was unable to replicate this, so it is a little harder to comment in
this. I don't fully understand why this happens, is this because of
something in the input file or because we move all DIEs with file

Would it be possible to attach the various temp files to the bug

> This can be explained as follows.  The DIEs written into the CU do not
> contain a single DW_AT_decl_file.  Consequently, htab_line will be NULL once
> we get here in write_multifile:
> ...
>              || (line_htab != NULL && write_multifile_line ()))
> ...
> and no .debug_line contribution will be added.  However, the CU DIE
> referencing the .debug_line contribution is written regardless.
> We could fix this by not writing the DW_AT_stmt_list for the CU DIE in this
> case, but that would require changing the order in which abbreviations are
> computed.
> Instead, fix this conservatively, by removing "line_htab != NULL &&", such we
> get a minimal .debug_line contribution.

This does look technically OK. write_multifile_line does handle line_htab == NULL
correctly and sets up multi_line_off which will be used to write the

But if the CU doesn't have a DW_AT_stmt_list this will produce an
unnecessary line table (stub). I cannot immediately see whether this
is an odd corner case that normally wouldn't happen in practice or if
that could happen more often.



  reply	other threads:[~2021-03-04  0:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 13:57 Tom de Vries
2021-03-04  0:33 ` Mark Wielaard [this message]
2021-03-04  8:33   ` Tom de Vries
2021-03-05  0:32     ` 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:

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

  git send-email \ \ \ \ \ \

* 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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).