Commit Graph

9 Commits

Author SHA1 Message Date
Igor Kudrin def677194c [DebugInfo] Report the format of location and range lists [9/10]
Differential Revision: https://reviews.llvm.org/D80523
2020-06-02 17:55:31 +07:00
Igor Kudrin 2094c5d292 [DebugInfo] Dump values in .debug_loclists and .debug_rnglists according to the DWARF format (5/8).
The patch changes dumping of a unit_length field and offsets in headers
in .debug_loclists and .debug_rnglists sections so that they are printed
as 16-digit hex values if the contribution is in the DWARF64 format.

Differential Revision: https://reviews.llvm.org/D79997
2020-05-19 13:35:41 +07:00
Igor Kudrin f92a554516 [DebugInfo] Dump form values according to the DWARF format (2/8).
The patch changes dumping of DWARF form values which sizes depend on
the DWARF format so that they are printed as 16-digit hex values for
DWARF64.

Differential Revision: https://reviews.llvm.org/D79997
2020-05-19 13:35:07 +07:00
David Blaikie e0fd87cc64 llvm-dwarfdump: Return non-zero on error
Makes it easier to test "this doesn't produce an error" (& indeed makes
that the implied default so we don't accidentally write tests that have
silent/sneaky errors as well as the positive behavior we're testing for)

Though the support for applying relocations is patchy enough that a
bunch of tests treat lack of relocation application as more of a warning
than an error - so rather than me trying to figure out how to add
support for a bunch of relocation types, let's degrade that to a warning
to match the usage (& indeed, it's sort of more of a tool warning anyway
- it's not that the DWARF is wrong, just that the tool can't fully cope
with it - and it's not like the tool won't dump the DWARF, it just won't
follow/render certain relocations - I guess in the most general case it
might try to render an unrelocated value & instead render something
bogus... but mostly seems to be about interesting relocations used in
eh_frame (& honestly it might be nice if we were lazier about doing this
relocation resolution anyway - if you're not dumping eh_frame, should we
really be erroring about the relocations in it?))
2020-04-09 20:53:58 -07:00
Fangrui Song d840e54523 [DebugInfo][test] Fix section flags/type to avoid warning/error in the future
A future MC change may add a warning/error when a .section directive
specifies incorrect sh_flags/sh_type. Fix the tests to use correct
sh_flags/sh_type.
2020-02-18 20:51:41 -08:00
Igor Kudrin 6f635f9092 [DWARF] Check that all fields of a Unit Header are read.
Tests "dwarfdump-rnglists-dwarf64.s" and "dwarfdump-rnglists.s" were
malformed because they had missing required DWO ID fields in split
compilation unit headers. The patch fixes the tests and checks
the reading of a unit header more thoroughly.

Differential Revision: https://reviews.llvm.org/D71704
2019-12-24 09:38:20 +07:00
Pavel Labath 4ee76a922a [llvm/DWARF] Return section offset from DWARFUnit::get{Loc,Rng}listOffset
Summary:
Currently these function return the raw content of the appropriate table
header, which means they are relative to the DW_AT_{loc,rng}list_base,
and one has to relocate them in order to do anything.

This changes the functions to perform the relocation themselves, which
seems more clearer, particularly as they are sitting right next to the
find{Rng,Loc}listFromOffset functions, but one *cannot* simply take the
result of these functions and take pass them there.

The only effect of this patch is to change what value is dumped for the
DW_AT_ranges attribute, which I think is for the better, as previously
the values appeared to point into thin air.

(The main reason I am looking at this is because I was trying to
implement equivalent functionality in lldb's DWARFUnit, and was stumped
by this behavior.

Reviewers: dblaikie, JDevlieghere, aprantl

Subscribers: hiraditya, llvm-commits, SouraVX

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D71006
2019-12-05 12:35:09 +01:00
David Blaikie d295087639 DebugInfo: Templatize rnglist header parsing to setup for reuse with loclist header parsing 2019-11-15 16:23:02 -08:00
Igor Kudrin e46639620d [DWARF] Fix referencing Range List Tables from CUs for DWARF64.
As DW_AT_rnglists_base points after the header and headers have
different sizes for DWARF32 and DWARF64, we have to use the format
of the CU to adjust the offset correctly in order to extract
the referenced range list table.

The patch also changes the type of RangeSectionBase because in DWARF64
it is 8-bytes long.

Differential Revision: https://reviews.llvm.org/D67098

llvm-svn: 371016
2019-09-05 07:02:28 +00:00