<feed xmlns='http://www.w3.org/2005/Atom'>
<title>go/src/debug/dwarf/testdata, branch makepkg</title>
<subtitle>Fork of Go programming language with my patches.</subtitle>
<id>http://git.kilabit.info/go/atom?h=makepkg</id>
<link rel='self' href='http://git.kilabit.info/go/atom?h=makepkg'/>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/'/>
<updated>2025-03-10T16:05:58Z</updated>
<entry>
<title>debug/dwarf: fix problem with DWARF 5 and Seek method</title>
<updated>2025-03-10T16:05:58Z</updated>
<author>
<name>Than McIntosh</name>
<email>thanm@golang.org</email>
</author>
<published>2025-03-07T19:16:28Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=e256e640604bff7916ef09451da7f4a6423152a6'/>
<id>urn:sha1:e256e640604bff7916ef09451da7f4a6423152a6</id>
<content type='text'>
When clients use debug/dwarf to examine DWARF 5 binaries, we can run
into problems when the Seek() method is used to skip ahead from a DIE
in one compilation unit to a DIE in another unit. The problem here is
that it is common for DWARF 5 comp units to have attributes (ex:
DW_AT_addr_base) whose value must be applied as an offset when reading
certain forms (ex: DW_FORM_addrx) within that unit. The existing
implementation didn't have a good way to recover these attrs following
the Seek call, and had to essentially punt in this case, resulting in
incorrect attr values.

This patch adds new support for reading and caching the key comp unit
DIE attributes (DW_AT_addr_base, DW_AT_loclists_base, etc) prior to
visiting any of the DIE entries in a unit, storing the cache values of
these attrs the main table of units. This base attribute
reading/caching behavior also happens (where needed) after Seek calls.

Should resolve delve issue 3861.
Supercedes Go pull request 70400.

Updates #26379.
Fixes #57046.

Change-Id: I536a57e2ba4fc55132d91c7f36f67a91ac408dc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/655976
Reviewed-by: Alessandro Arzilli &lt;alessandro.arzilli@gmail.com&gt;
Reviewed-by: Cherry Mui &lt;cherryyz@google.com&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@google.com&gt;
LUCI-TryBot-Result: Go LUCI &lt;golang-scoped@luci-project-accounts.iam.gserviceaccount.com&gt;
</content>
</entry>
<entry>
<title>debug/elf: support zstd compression</title>
<updated>2023-04-18T20:34:36Z</updated>
<author>
<name>Ian Lance Taylor</name>
<email>iant@golang.org</email>
</author>
<published>2023-03-03T22:29:44Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=48a1dcb92778a349e13bcb8be10a40047f0cf7d1'/>
<id>urn:sha1:48a1dcb92778a349e13bcb8be10a40047f0cf7d1</id>
<content type='text'>
Test cases added to debug/dwarf because that is where it matters in practice.

The new test binary line-gcc-zstd.elf built with

    gcc -g -no-pie -Wl,--compress-debug-sections=zstd line[12].c

using

    gcc (Debian 12.2.0-10) 12.2.0

with a development version of the GNU binutils.

Fixes #55107

Change-Id: I48507c96902e1f83a174e5647b5cc403d965b52b
Reviewed-on: https://go-review.googlesource.com/c/go/+/473256
TryBot-Result: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@google.com&gt;
Run-TryBot: Ian Lance Taylor &lt;iant@google.com&gt;
Run-TryBot: Ian Lance Taylor &lt;iant@golang.org&gt;
Auto-Submit: Ian Lance Taylor &lt;iant@google.com&gt;
Reviewed-by: Than McIntosh &lt;thanm@google.com&gt;
</content>
</entry>
<entry>
<title>debug/dwarf: fix problems with handling of bit offsets for bitfields</title>
<updated>2022-01-28T20:07:54Z</updated>
<author>
<name>Than McIntosh</name>
<email>thanm@google.com</email>
</author>
<published>2022-01-25T14:34:35Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=8314544bd6b3c5f0bee89a6bd411ced0aeba1a8c'/>
<id>urn:sha1:8314544bd6b3c5f0bee89a6bd411ced0aeba1a8c</id>
<content type='text'>
This patch reworks the handling of the DWARF DW_AT_bit_offset and
DW_AT_data_bit_offset attributes to resolve problems arising from
a previous related change (CL 328709).

In CL 328709 the DWARF type reader was updated to look for and use
the DW_AT_data_bit_offset attribute for structure fields, handling
the value of the attribute in the same way as for DW_AT_bit_offset.
This caused problems for clients, since the two attributes have very
different semantics.

This CL effectively reverts CL 328709 and moves to a scheme in which
we detect and report the two attributes separately/independently.

This patch also corrects a problem in the DWARF type reader in the
code that detects and fixes up the type of struct fields corresponding
to zero-length arrays; the code in question was testing the
DW_AT_bit_offset attribute value but assuming DW_AT_data_bit_offset
semantics, meaning that it would fail to fix up cases such as

  typedef struct another_struct {
    unsigned short quix;
    int xyz[0];
    unsigned  x:1;
    long long array[40];
  } t;

The code in question has been changed to avoid using BitOffset and
instead consider only ByteOffset and BitSize.

Fixes #50685.
Updates #46784.

Change-Id: Ic15ce01c851af38ebd81af827973ec49badcab6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/380714
Trust: Than McIntosh &lt;thanm@google.com&gt;
Run-TryBot: Than McIntosh &lt;thanm@google.com&gt;
TryBot-Result: Gopher Robot &lt;gobot@golang.org&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
</content>
</entry>
<entry>
<title>debug/dwarf: check for DWARFv4 AttrDataBitOffset value</title>
<updated>2021-09-02T19:56:24Z</updated>
<author>
<name>Joe Sylve</name>
<email>joe.sylve@gmail.com</email>
</author>
<published>2021-09-02T19:09:15Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=065f3808156c92d957fc1ad2a2a37e147ee628f4'/>
<id>urn:sha1:065f3808156c92d957fc1ad2a2a37e147ee628f4</id>
<content type='text'>
AttrBitOffset is deprecated (but reserved) in DWARFv4.  This fix adds
logic to check the new AttrDataBitOffset attribute if AttrBitOffset
attribute is not present.

Fixes #46784

Change-Id: I7406dcaa4c98e95df72361fd4462c39e6be8879d
GitHub-Last-Rev: 5aa10d04910a09538320b4de8fbd8a1f5fd8c17d
GitHub-Pull-Request: golang/go#46790
Reviewed-on: https://go-review.googlesource.com/c/go/+/328709
Run-TryBot: Than McIntosh &lt;thanm@google.com&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
Trust: Michael Knyszek &lt;mknyszek@google.com&gt;
</content>
</entry>
<entry>
<title>debug/dwarf: support DW_FORM_rnglistx aka formRnglistx</title>
<updated>2021-03-17T00:54:09Z</updated>
<author>
<name>Ian Lance Taylor</name>
<email>iant@golang.org</email>
</author>
<published>2021-03-16T20:31:20Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=a826f7dc45f2e0f210341893bd70740aef6b777d'/>
<id>urn:sha1:a826f7dc45f2e0f210341893bd70740aef6b777d</id>
<content type='text'>
Change-Id: I7df915978af3488f46a27595a1b04d0d33f81f7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/302369
Trust: Ian Lance Taylor &lt;iant@golang.org&gt;
Run-TryBot: Ian Lance Taylor &lt;iant@golang.org&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Than McIntosh &lt;thanm@google.com&gt;
</content>
</entry>
<entry>
<title>debug/dwarf: don't try to parse addr/rnglists header</title>
<updated>2020-12-14T18:06:06Z</updated>
<author>
<name>Ian Lance Taylor</name>
<email>iant@golang.org</email>
</author>
<published>2020-12-11T23:15:43Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=828746ec57e76e49527791bca500b27b77576d79'/>
<id>urn:sha1:828746ec57e76e49527791bca500b27b77576d79</id>
<content type='text'>
In an executable, the debug_addr and debug_rnglists sections are
assembled by concatenating the input sections, and each input section
has a header, and each header may have different attributes. So just
parsing the single header isn't right.  Parsing the header is not
necessary to handle offsets into these sections which is all we do.

Looking at the header is also problematic because GCC with
-gsplit-dwarf when using DWARF versions 2 through 4 emits a
.debug_addr section, but it has no header.  The header was only added
for DWARF 5. So we can't parse the header at all for that case, and we
can't even detect that case in general.

This CL also fixes SeekPC with addrx and strx formats, by not using
the wrong compilation unit to find the address or string base.
To make that work when parsing the compilation unit itself, we add
support for delay the resolution of those values until we know the base.

New test binaries built with

gcc -gdwarf-5 -no-pie debug/dwarf/testdata/line[12].c
(gcc (Debian 10.2.0-15) 10.2.0)

clang -gdwarf-5 -no-pie debug/dwarf/testdata/line[12].c
(clang version 9.0.1-14)

Change-Id: I66783e0eded629bf80c467767f781164d344a54d
Reviewed-on: https://go-review.googlesource.com/c/go/+/277233
Trust: Ian Lance Taylor &lt;iant@golang.org&gt;
Reviewed-by: Than McIntosh &lt;thanm@google.com&gt;
</content>
</entry>
<entry>
<title>debug/dwarf: add support for DWARFv5 to (*Data).Ranges</title>
<updated>2020-10-24T04:11:41Z</updated>
<author>
<name>Alessandro Arzilli</name>
<email>alessandro.arzilli@gmail.com</email>
</author>
<published>2020-06-04T14:59:06Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=05b6118139d880a5bced23da9d07bdb0db8e7084'/>
<id>urn:sha1:05b6118139d880a5bced23da9d07bdb0db8e7084</id>
<content type='text'>
Updates the (*Data).Ranges method to work with DWARFv5 which uses the
new debug_rnglists section instead of debug_ranges.

This does not include supporting DW_FORM_rnglistx.

General support for DWARFv5 was added by CL 175138.

Change-Id: I01f919a865616a3ff12f5bf649c2c9abf89fcf52
Reviewed-on: https://go-review.googlesource.com/c/go/+/236657
Run-TryBot: Ian Lance Taylor &lt;iant@golang.org&gt;
TryBot-Result: Go Bot &lt;gobot@golang.org&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
Trust: Emmanuel Odeke &lt;emm.odeke@gmail.com&gt;
</content>
</entry>
<entry>
<title>debug/dwarf: more graceful handling of unsupported types</title>
<updated>2019-03-15T17:33:46Z</updated>
<author>
<name>Than McIntosh</name>
<email>thanm@google.com</email>
</author>
<published>2019-01-18T20:16:11Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=c135dfbf1842993aa2fd4c293b2476ce4733daf7'/>
<id>urn:sha1:c135dfbf1842993aa2fd4c293b2476ce4733daf7</id>
<content type='text'>
Enhance the type decoder to do a better job handling unknown type
tags. DWARF has a number of type DIEs that this package doesn't handle
(things like "pointer to member" types in C++); avoid crashing for
such types, but instead return a placeholder "UnsupportedType" object
(this idea suggested by Austin). This provides a compromise between
implementing the entire kitchen sink and simply returning an error
outright on any unknown type DIE.

Fixes #29601.

Change-Id: I2eeffa094c86ef3a2c358ee42e8e629d74cec2ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/158797
Reviewed-by: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
Run-TryBot: Brad Fitzpatrick &lt;bradfitz@golang.org&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</content>
</entry>
<entry>
<title>debug/dwarf: heuristically handle both UNIX and Windows paths</title>
<updated>2017-05-26T14:35:20Z</updated>
<author>
<name>Austin Clements</name>
<email>austin@google.com</email>
</author>
<published>2017-05-24T20:21:01Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=c31231ccab371b31f5563a91e68720657799fe70'/>
<id>urn:sha1:c31231ccab371b31f5563a91e68720657799fe70</id>
<content type='text'>
Currently debug/dwarf assumes all paths in line tables will be
UNIX-style paths, which obviously isn't the case for binaries built on
Windows. However, we can't simply switch from the path package to the
filepath package because we don't know that we're running on the same
host type that built the binary and we want this to work even if we're
not. This is essentially the approach taken by GDB, which treats paths
in accordance with the system GDB itself is compiled for. In fact, we
can't even guess the compilation system from the type of the binary
because it may have been cross-compiled.

We fix this by heuristically determining whether paths are UNIX-style
or DOS-style by looking for a drive letter or UNC path. If we see a
DOS-style path, we use appropriate logic for determining whether the
path is absolute and for joining two paths. This is helped by the fact
that we should basically always be starting with an absolute path.
However, it could mistake a relative UNIX-style path that begins with
a directory like "C:" for an absolute DOS-style path. There doesn't
seem to be any way around this.

Fixes #19784.

Change-Id: Ie13b546d2f1dcd8b02e668583a627b571b281588
Reviewed-on: https://go-review.googlesource.com/44017
Run-TryBot: Austin Clements &lt;austin@google.com&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
Reviewed-by: Ian Lance Taylor &lt;iant@golang.org&gt;
Reviewed-by: Alex Brainman &lt;alex.brainman@gmail.com&gt;
</content>
</entry>
<entry>
<title>debug/dwarf: add Reader.SeekPC and Data.Ranges</title>
<updated>2016-03-22T14:06:09Z</updated>
<author>
<name>Ian Lance Taylor</name>
<email>iant@golang.org</email>
</author>
<published>2016-03-16T21:15:54Z</published>
<link rel='alternate' type='text/html' href='http://git.kilabit.info/go/commit/?id=d1b8871f13203cd99d5e7d686170f0e266760084'/>
<id>urn:sha1:d1b8871f13203cd99d5e7d686170f0e266760084</id>
<content type='text'>
These new methods help find the compilation unit to pass to the
LineReader method in order to find the line information for a PC.
The Ranges method also helps identify the specific function for a PC,
needed to determine the function name.

This uses the .debug.ranges section if necessary, and changes the object
file format packages to pass in the section contents if available.

Change-Id: I5ebc3d27faaf1a126ffb17a1e6027efdf64af836
Reviewed-on: https://go-review.googlesource.com/20769
Reviewed-by: Austin Clements &lt;austin@google.com&gt;
Run-TryBot: Ian Lance Taylor &lt;iant@golang.org&gt;
TryBot-Result: Gobot Gobot &lt;gobot@golang.org&gt;
</content>
</entry>
</feed>
