From: Tom de Vries <tdevries@suse.de>
To: dwz@sourceware.org, jakub@redhat.com, mark@klomp.org
Subject: [PATCH] Fix .debug_line reference above end of section
Date: Tue, 2 Mar 2021 14:57:14 +0100 [thread overview]
Message-ID: <20210302135713.GA22526@delia> (raw)
Hi,
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/gen-dwz-debug-all.sh 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.
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.
Any comments?
Thanks,
- Tom
Fix .debug_line reference above end of section
2021-03-02 Tom de Vries <tdevries@suse.de>
PR dwz/26738
* dwz.c (write_multifile): Also call write_multifile_line when
line_htab == NULL.
---
dwz.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dwz.c b/dwz.c
index af1c5af..5effbc1 100644
--- a/dwz.c
+++ b/dwz.c
@@ -15150,7 +15150,7 @@ write_multifile (DSO *dso)
debug_sections[DEBUG_MACRO].new_size)
!= (ssize_t) debug_sections[DEBUG_MACRO].new_size)
|| (strp_htab != NULL && write_multifile_strp ())
- || (line_htab != NULL && write_multifile_line ()))
+ || write_multifile_line ())
{
error (0, 0, "Error writing multi-file temporary files");
ret = 1;
next reply other threads:[~2021-03-02 13:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 13:57 Tom de Vries [this message]
2021-03-04 0:33 ` Mark Wielaard
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:
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=20210302135713.GA22526@delia \
--to=tdevries@suse.de \
--cc=dwz@sourceware.org \
--cc=jakub@redhat.com \
--cc=mark@klomp.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).