Revert "[llvm][DebugInfo] Attach object-pointer to DISubprogram declarations (#122742)" (#124853)

This introduces a substantial (5-10%) regression in .debug_info size, so
we're discussing alternati

Revert "[llvm][DebugInfo] Attach object-pointer to DISubprogram declarations (#122742)" (#124853)

This introduces a substantial (5-10%) regression in .debug_info size, so
we're discussing alternatives in #122742 and #124790.

This reverts commit 7c729418d721147bf1f2b257afd30f84721888ad.

show more ...

[llvm][DebugInfo] Attach object-pointer to DISubprogram declarations (#122742)

Currently Clang only attaches `DW_AT_object_pointer` to
`DW_TAG_subprogram` definitions. LLDB constructs C++ method ty

[llvm][DebugInfo] Attach object-pointer to DISubprogram declarations (#122742)

Currently Clang only attaches `DW_AT_object_pointer` to
`DW_TAG_subprogram` definitions. LLDB constructs C++ method types from
their `DW_TAG_subprogram` declaration, which is also the point at which
it needs to determine whether a method is static or not. LLDB's
heuristic for this could be very simple if we emitted
`DW_AT_object_pointer` on declarations. But since we don't, LLDB has to
guess whether an argument is an implicit object parameter based on the
DW_AT_name and DW_AT_type.

To simplify LLDB's job (and to eventually support C++23's explicit
object parameters), this patch adds the `DIFlagObjectPointer` to
`DISubprogram` declarations.

For reference, GCC attaches the object-pointer DIE to both the
definition and declaration: https://godbolt.org/z/3TWjTfWon

Fixes https://github.com/llvm/llvm-project/issues/120973

show more ...

Revert "[X86] Use the CFA as the DWARF frame base for better variable locations around calls."

This reverts commit d421f5226048e4a5d88aab157d0f4d434c43f208.

LLDB tests are failing as shown in
https

Revert "[X86] Use the CFA as the DWARF frame base for better variable locations around calls."

This reverts commit d421f5226048e4a5d88aab157d0f4d434c43f208.

LLDB tests are failing as shown in
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/55133/testReport/

show more ...

[X86] Use the CFA as the DWARF frame base for better variable locations around calls.

Prior to this patch, for the DWARF frame base LLVM uses the frame pointer
register if available, otherwise the s

[X86] Use the CFA as the DWARF frame base for better variable locations around calls.

Prior to this patch, for the DWARF frame base LLVM uses the frame pointer
register if available, otherwise the stack pointer register. If the stack
pointer register is being used and a call or other code modifies the stack
pointer during the body of the function this results in the locations being
wrong and the debugger displaying the wrong values for variables.

By using DW_OP_call_frame_cfa in these situations the emitted location for
the variable will automatically handle changes in the stack pointer.
The CFA needs to be adjusted for the offset between the frame pointer/stack
pointer to allow the variable locations themselves to remain unchanged by
this patch.

Reviewed By: #debug-info, scott.linder, jryans

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

show more ...

llvm/tools: Convert tests to opaque pointers

[llvm-dwarfdump] Fix unsigned overflow when calculating stats

This fixes https://bugs.llvm.org/show_bug.cgi?id=51652.

The idea is to bump all the stat fields to 64-bit wide
unsigned integers. I've

[llvm-dwarfdump] Fix unsigned overflow when calculating stats

This fixes https://bugs.llvm.org/show_bug.cgi?id=51652.

The idea is to bump all the stat fields to 64-bit wide
unsigned integers. I've confirmed this resolves
the use case for chromium.

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

show more ...

[llvm-dwarfdump] Fix abstract origin vars location stats calculation

There are cases where a concrete DIE with DW_TAG_subprogram can have
abstract_origin attribute, so we handle that situation as we

[llvm-dwarfdump] Fix abstract origin vars location stats calculation

There are cases where a concrete DIE with DW_TAG_subprogram can have
abstract_origin attribute, so we handle that situation as well.

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

show more ...

Revert "Use the default seed value for djb hash for StringMap"

This reverts commit d84440ec919019ac446241db72cfd905c6ac9dfa.

It breaks (at least) lldb and lld validation

https://lab.llvm.org/build

Revert "Use the default seed value for djb hash for StringMap"

This reverts commit d84440ec919019ac446241db72cfd905c6ac9dfa.

It breaks (at least) lldb and lld validation

https://lab.llvm.org/buildbot/#/builders/68/builds/7837
https://lab.llvm.org/buildbot/#/builders/36/builds/5495

show more ...

Use the default seed value for djb hash for StringMap

See original comment in 560ce2c70fb1fe8e4b9b5e39c54e494a50373ba8
Baiscally the default seed value results in less collision, but changes the
ite

Use the default seed value for djb hash for StringMap

See original comment in 560ce2c70fb1fe8e4b9b5e39c54e494a50373ba8
Baiscally the default seed value results in less collision, but changes the
iteration order, which matters for a few test cases.

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

show more ...

[llvm-dwarfdump] StringMap -> MapVector to make iteration order stable

Exposed by D97396

[llvm-dwarfdump][locstats] Unify handling of inlined vars with no loc

The presence or absence of an inline variable (as well as formal
parameter) with only an abstract_origin ref (without DW_AT_loca

[llvm-dwarfdump][locstats] Unify handling of inlined vars with no loc

The presence or absence of an inline variable (as well as formal
parameter) with only an abstract_origin ref (without DW_AT_location)
should not change the location coverage.

It means, for both:

DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x0000004e "f")
DW_AT_low_pc (0x0000000000000010)
DW_AT_high_pc (0x0000000000000013)
DW_TAG_formal_parameter
DW_AT_abstract_origin (0x0000005a "b")

and,

DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x0000004e "f")
DW_AT_low_pc (0x0000000000000010)
DW_AT_high_pc (0x0000000000000013)

we should report 0% location coverage. If we add DW_AT_location,
for both cases the coverage should be improved.

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

show more ...

[dwarfdump] Recognize __apple sections as debug info sections

Recognize the __apple_ sections as debug info sections and make sure
they're included in the --show-sections-sizes output.

Differential

[dwarfdump] Recognize __apple sections as debug info sections

Recognize the __apple_ sections as debug info sections and make sure
they're included in the --show-sections-sizes output.

Differential revision: https://reviews.llvm.org/D90433

show more ...

[llvm-dwarfdump] Fix misleading scope byte coverage statistics

Fixes PR46575.

Bump statistics version to 6.

Without this patch, for a variable described with a location list the stat
'sum_all_vari

[llvm-dwarfdump] Fix misleading scope byte coverage statistics

Fixes PR46575.

Bump statistics version to 6.

Without this patch, for a variable described with a location list the stat
'sum_all_variables(#bytes in parent scope covered by DW_AT_location)' is
calculated by summing all bytes covered by the location ranges in the list and
capping the result to the number of bytes in the parent scope. With the patch,
only bytes which overlap with the parent DIE scope address ranges contribute to
the stat. A new stat 'sum_all_variables(#bytes in any scope covered by
DW_AT_location)' has been added which displays the total bytes covered when
ignoring scopes.

show more ...

[llvm-dwarfdump] --statistics: break lines and indent by 2

so that the user does not have to pipe the output to `jq` or `python -m json.tool`.
This change makes testing more convenient because `-NEX

[llvm-dwarfdump] --statistics: break lines and indent by 2

so that the user does not have to pipe the output to `jq` or `python -m json.tool`.
This change makes testing more convenient because `-NEXT` patterns can be used.
The "prettify by default" is a good tradeoff to make. The output size increases a bit.

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

show more ...

[llvm-dwarfdump] Fix a typo: witin -> within

[llvm-dwarfdump][test] Add a --statistics test for a DW_AT_artificial variable

There is an untested but useful case: `this` (even if not written) is counted as a
source variable.

Reviewed By: dblai

[llvm-dwarfdump][test] Add a --statistics test for a DW_AT_artificial variable

There is an untested but useful case: `this` (even if not written) is counted as a
source variable.

Reviewed By: dblaikie

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

show more ...

[NFC][test] Add missing ':' after 'CHECK'

Without the ':' the check command doesn't do anything.
This typo was introduced along with the commit for the D77789.

[llvm-dwarfdump][Stats] Clean up

This addresses:
-Clean up the source code
-Refactor the JSON fields
-Fix the test cases
-Improve the docs for the stats output

Differential Revision: https:

[llvm-dwarfdump][Stats] Clean up

This addresses:
-Clean up the source code
-Refactor the JSON fields
-Fix the test cases
-Improve the docs for the stats output

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

show more ...

[llvm] Fix missing FileCheck directive colons

https://reviews.llvm.org/D77352

[llvm-dwarfdump] Add the --show-sections-sizes option

Add an option to llvm-dwarfdump to calculate the bytes within
the debug sections. Dump this numbers when using --statistics
option as well.

Thi

[llvm-dwarfdump] Add the --show-sections-sizes option

Add an option to llvm-dwarfdump to calculate the bytes within
the debug sections. Dump this numbers when using --statistics
option as well.

This is an initial patch (e.g. we should support other units,
since we only support 'bytes' now).

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

show more ...

[llvm-dwarfdump][Statistics] Distinguish parameters with same name or w/o a name

A few DW_TAG_formal_parameter's of the same function may have the same
name (e.g. variadic (template) functions) or d

[llvm-dwarfdump][Statistics] Distinguish parameters with same name or w/o a name

A few DW_TAG_formal_parameter's of the same function may have the same
name (e.g. variadic (template) functions) or don't have a name at all
(if the parameter isn't used inside the function body), but we still
need to be able to distinguish between them to get correct number of 'total vars'
and 'availability' metric.

Reviewed by: aprantl

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

show more ...

[llvm-dwarfdump][Statistics] Ignore declarations of global variables

Reviewed by: djtodoro

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

[llvm-dwarfdump][Statistics] Ignore DW_TAG_subroutine_type in statistics

DW_TAG_subroutine_type is not really useful for statistics purposes, as it never
has location information. But it may contain

[llvm-dwarfdump][Statistics] Ignore DW_TAG_subroutine_type in statistics

DW_TAG_subroutine_type is not really useful for statistics purposes, as it never
has location information. But it may contain DW_TAG_formal_parameter
children that generate number of parameters w/o location and decrease
'availability' metric significantly.

Reviewed by: djtodoro

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

show more ...

[llvm-dwarfdump][Statistics] Unify coverage statistic computation

Summary:
The patch removes OffsetToFirstDefinition in the 'scope bytes total'
statistic computation. Thus it unifies the way the sco

[llvm-dwarfdump][Statistics] Unify coverage statistic computation

Summary:
The patch removes OffsetToFirstDefinition in the 'scope bytes total'
statistic computation. Thus it unifies the way the scope and the coverage
buckets are computed. The rationals behind that are the following:

1. OffsetToFirstDefinition was used to calculate the variable's life range.
However, there is no simple way to do it accurately, so the scope calculated
this way might be misleading. See D69027 for more details on the subject.
2. Both 'scope bytes total' and coverage buckets seem to be intended
to represent the same data in different ways. Otherwise, the statistics
might be controversial and confusing.

Note that the approach gives up a thorough evaluation of debug information
completeness (i.e. coverage buckets by themselves doesn't tell how good
the debug information is). Only changes in coverage over time make
a 'physical' sense.

Reviewers: djtodoro, aprantl, vsk, dblaikie, avl

Subscribers: llvm-commits

Tags: #llvm

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

show more ...

llvm-dwarfdump: Add new variable, parameter and inlining statistics; also function source location statistics.

Add statistics for abstract origins, function, variable and parameter
locations; break

llvm-dwarfdump: Add new variable, parameter and inlining statistics; also function source location statistics.

Add statistics for abstract origins, function, variable and parameter
locations; break the 'variable' counts down into variables and
parameters. Also update call site counting to check for
DW_AT_call_{file,line} in addition to DW_TAG_call_site.

Differential revision: https://reviews.llvm.org/D58849

llvm-svn: 355243

show more ...