.debug_gnu_pub{names,types}: Stabilize iteration order

StringMap iteration order is not guaranteed to be deterministic
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).
Sort by DI

.debug_gnu_pub{names,types}: Stabilize iteration order

StringMap iteration order is not guaranteed to be deterministic
(https://llvm.org/docs/ProgrammersManual.html#llvm-adt-stringmap-h).
Sort by DIE offset (which looks like a pre-order traversal order).

show more ...

[DwarfDebug] Move emission of imported entities from beginModule() to endModule() (2/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-lo

[DwarfDebug] Move emission of imported entities from beginModule() to endModule() (2/7)

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544

!Note! Extracted from the following patch for review purpose only, should
be squashed with the next patch (D144004) before committing.

Currently the back-end emits imported entities in `DwarfDebug::beginModule()`.
However in case an imported declaration is a function, it must point to an
abstract subprogram if it exists (see PR51501). But in `DwarfDebug::beginModule()`
the DWARF generator doesn't have information to identify if an abstract
subprogram needs to be created.

Only by entering `DwarfDebug::endModule()` all subprograms are processed,
so it's clear which subprogram DIE should be referred to. Hence, the patch moves
the emission there.

The patch is need to fix PR51501, but it only does the preliminary
work. Since it changes the order of debug entities in emitted DWARF and
therefore affect many tests it's separated from the fix for the sake of
simplifying review.

Note that there are other issues with handling an imported declaration in
`DwarfDebug::beginModule()`. They are described in more details in D114705.

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

Depends on D143984

show more ...

Recommit "[Support] change StringMap hash function from djbHash to xxHash"

This reverts commit 37eb9d13f891f7656f811516e765b929b169afe0.

Test failures have been fixed:

- ubsan failure fixed by 72e

Recommit "[Support] change StringMap hash function from djbHash to xxHash"

This reverts commit 37eb9d13f891f7656f811516e765b929b169afe0.

Test failures have been fixed:

- ubsan failure fixed by 72eac42f21c0f45a27f3eaaff9364cbb5189b9e4
- warn-unsafe-buffer-usage-fixits-local-var-span.cpp fixed by
03cc52dfd1dbb4a59b479da55e87838fb93d2067 (wasn't related)
- test-output-format.ll failure was spurious, build failed at
https://lab.llvm.org/buildbot/#/builders/54/builds/3545 (b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93)
but passed at
https://lab.llvm.org/buildbot/#/builders/54/builds/3546 (5ae99be0377248c74346096dc475af254a3fc799)
which is before my revert
https://github.com/llvm/llvm-project/compare/b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93...5ae99be0377248c74346096dc475af254a3fc799

Original commit message:

Depends on https://reviews.llvm.org/D142861.

Alternative to https://reviews.llvm.org/D137601.

xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile.

Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order.
No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed.

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

show more ...

Revert "[Support] change StringMap hash function from djbHash to xxHash"

This reverts commit d768b97424f9e1a0aae45440a18b99f21c4027ce.

Causes sanitizer failure: https://lab.llvm.org/buildbot/#/buil

Revert "[Support] change StringMap hash function from djbHash to xxHash"

This reverts commit d768b97424f9e1a0aae45440a18b99f21c4027ce.

Causes sanitizer failure: https://lab.llvm.org/buildbot/#/builders/238/builds/1114

```
/b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Support/xxhash.cpp:107:12: runtime error: applying non-zero offset 8 to null pointer
#0 0xaaaab28ec6c8 in llvm::xxHash64(llvm::StringRef) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Support/xxhash.cpp:107:12
#1 0xaaaab28cbd38 in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) /b/sanitizer-aarch64-linux-bootstrap-ubsan/build/llvm-project/llvm/lib/Support/StringMap.cpp:87:28
```

Probably causes test failure in `warn-unsafe-buffer-usage-fixits-local-var-span.cpp`: https://lab.llvm.org/buildbot/#/builders/60/builds/10619

Probably causes reverse-iteration test failure in `test-output-format.ll`: https://lab.llvm.org/buildbot/#/builders/54/builds/3545

show more ...

[Support] change StringMap hash function from djbHash to xxHash

Depends on https://reviews.llvm.org/D142861.

Alternative to https://reviews.llvm.org/D137601.

xxHash is much faster than djbHash. Th

[Support] change StringMap hash function from djbHash to xxHash

Depends on https://reviews.llvm.org/D142861.

Alternative to https://reviews.llvm.org/D137601.

xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile.

Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order.
No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed.

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

show more ...

[DebugInfo] Convert most tests to opaque pointers (NFC)

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches

Try to revert D113741 once again.

This also reverts 0ac75e82fff93a80ca401d3db3541e8d1d9098f

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches

Try to revert D113741 once again.

This also reverts 0ac75e82fff93a80ca401d3db3541e8d1d9098f9 (D114705)
as it causes LLDB's lldb-api.lang/cpp/nsimport.TestCppNsImport.py test
failure w/o D113741.

This reverts commit f9607d45f399e2afc39ec16222ea68b4e0831564.

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

show more ...

Reland [DwarfDebug] Move emission of global vars, types and imports to endModule()

This patch proposes to move emission of global variables, types,
imported entities, etc from DwarfDebug::beginModul

Reland [DwarfDebug] Move emission of global vars, types and imports to endModule()

This patch proposes to move emission of global variables, types,
imported entities, etc from DwarfDebug::beginModule() to DwarfDebug::endModule().
Effectively, this changes nothing but the order of debug entities which
will be as follows:
* subprograms (including related context, local variables/labels,
local imported entities; related types can be created as a part of
the emission of local entities of an abstract subprogram);
* global variables (including related context and types);
* retained types and enums;
* non-local-scoped imported entities;
* basic types;
* other types left (as a part of local variables attributes emission).

Note that the order of emitted compile units may also be changed as now we emit
units that contain subprograms first and then all other non-empty units.

The motivation behind this change is the following:
(1) DwarfDebug::beginModule() is run at the very beginning of backend's pipeline,
from this time IR can be significantly changed by target-specific passes.
If it happens for debug metadata of global entities, those changes will not
be reflected in the emitted DWARF.
(2) imported subprogram names should refer to an abstract subprogram if it exists,
but it isn't known in DwarfDebug::beginModule() (it's possible to make some
guesses based on location info, but it's not quite reliable);
(3) aforementioned entities if they are scoped within a bracketed block
(subject of D113741) couldn't be emitted in DwarfDebug::beginModule()
(they need parent emitted first). Another problem is if to try to gather
some information about local entities and defer their emission
(till subprogram's processing or DwarfDebug::endModule()) all the gathered
details might be irrelevant / invalid by the time the entities are being
emitted (because of (1)).

Reviewed By: dblaikie

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

show more ...

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block"

This reverts commits
* ee691970a9a85470948ada623c31f0ab8773617c (D113741),
* 79d3132998b2828be8f7d2ec411f91fb11b

Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block"

This reverts commits
* ee691970a9a85470948ada623c31f0ab8773617c (D113741),
* 79d3132998b2828be8f7d2ec411f91fb11b3e01f (D114705)

due to lldb and dexter test failures.

show more ...

[DwarfDebug] Move emission of global vars, types and imports to endModule()

This patch proposes to move emission of global variables, types,
imported entities, etc from DwarfDebug::beginModule() to

[DwarfDebug] Move emission of global vars, types and imports to endModule()

This patch proposes to move emission of global variables, types,
imported entities, etc from DwarfDebug::beginModule() to DwarfDebug::endModule().
Effectively, this changes nothing but the order of debug entities which
will be as follows:
* subprograms (including related context, local variables/labels,
local imported entities; related types can be created as a part of
the emission of local entities of an abstract subprogram);
* global variables (including related context and types);
* retained types and enums;
* non-local-scoped imported entities;
* basic types;
* other types left (as a part of local variables attributes emission).

Note that the order of emitted compile units may also be changed as now we emit
units that contain subprograms first and then all other non-empty units.

The motivation behind this change is the following:
(1) DwarfDebug::beginModule() is run at the very beginning of backend's pipeline,
from this time IR can be significantly changed by target-specific passes.
If it happens for debug metadata of global entities, those changes will not
be reflected in the emitted DWARF.
(2) imported subprogram names should refer to an abstract subprogram if it exists,
but it isn't known in DwarfDebug::beginModule() (it's possible to make some
guesses based on location info, but it's not quite reliable);
(3) aforementioned entities if they are scoped within a bracketed block
(subject of D113741) couldn't be emitted in DwarfDebug::beginModule()
(they need parent emitted first). Another problem is if to try to gather
some information about local entities and defer their emission
(till subprogram's processing or DwarfDebug::endModule()) all the gathered
details might be irrelevant / invalid by the time the entities are being
emitted (because of (1)).

Reviewed By: dblaikie

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

show more ...

[DebugInfo][test] Simplify/improve a few tests using --impicit-check-not=DW_TAG. NFC

This patch rewrites checks in a few debug info tests to avoid using
'CHECK-NOT: {{DW_TAG|NULL}}'. It proposes `--

[DebugInfo][test] Simplify/improve a few tests using --impicit-check-not=DW_TAG. NFC

This patch rewrites checks in a few debug info tests to avoid using
'CHECK-NOT: {{DW_TAG|NULL}}'. It proposes `--impicit-check-not=DW_TAG`
instead, as it makes the checks clearer, and easier to analyze and update.

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

show more ...

Revert "[NFC] remove explicit default value for strboolattr attribute in tests"

This reverts commit bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247.

See https://lab.llvm.org/buildbot/#/builders/109/builds

Revert "[NFC] remove explicit default value for strboolattr attribute in tests"

This reverts commit bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247.

See https://lab.llvm.org/buildbot/#/builders/109/builds/15424 for instance

show more ...

[NFC] remove explicit default value for strboolattr attribute in tests

Since d6de1e1a71406c75a4ea4d5a2fe84289f07ea3a1, no attributes is quivalent to
setting attribute to false.

This is a preliminar

[NFC] remove explicit default value for strboolattr attribute in tests

Since d6de1e1a71406c75a4ea4d5a2fe84289f07ea3a1, no attributes is quivalent to
setting attribute to false.

This is a preliminary commit for https://reviews.llvm.org/D99080

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 ...

[DebugInfo] Separate fields with commas in headers of .debug_pub* tables (1/3).

For most tables, we already use commas in headers. This set of patches
unifies dumping the remaining ones.

Differenti

[DebugInfo] Separate fields with commas in headers of .debug_pub* tables (1/3).

For most tables, we already use commas in headers. This set of patches
unifies dumping the remaining ones.

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

show more ...

Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" as cleanups after D56351

DebugInfo: Update support for detecting C++ language variants in debug info emission

llvm-svn: 373420

DebugInfo: Include enumerators in pubnames

This is consistent with GCC's behavior (which is the defacto standard
for pubnames). Though I find the presence of enumerators from enum
classes to be a bi

DebugInfo: Include enumerators in pubnames

This is consistent with GCC's behavior (which is the defacto standard
for pubnames). Though I find the presence of enumerators from enum
classes to be a bit confusing, possibly a bug on GCC's end (since they
can't be named unqualified, unlike the other names - and names nested in
classes don't go in pubnames, for instance - presumably because one must
name the class first & that's enough to limit the scope of the search)

llvm-svn: 363349

show more ...

[AsmPrinter] Fix DebugInfo/X86/gnu-public-names.ll after rL346790

llvm-svn: 346797

[AsmPrinter] Rename a comment of .debug_gnu_pubnames entry

Summary:
The comment refers to the field as "Kind:". However, in gdb,

https://sourceware.org/gdb//onlinedocs/gdb/Index-Section-Format.html

[AsmPrinter] Rename a comment of .debug_gnu_pubnames entry

Summary:
The comment refers to the field as "Kind:". However, in gdb,

https://sourceware.org/gdb//onlinedocs/gdb/Index-Section-Format.html names it "attributes",
gdb/dwarf2read.c:dw2_symtab_iter_next refers to the whole value as "cu_index_and_attrs"

Change it to `Attributes:` for consistency.

Reviewers: dblaikie

Reviewed By: dblaikie

Subscribers: aprantl, JDevlieghere, arphaman, llvm-commits

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

llvm-svn: 346790

show more ...

DebugInfo: Add metadata support for disabling DWARF pub sections

In cases where the debugger load time is a worthwhile tradeoff (or less
costly - such as loading from a DWP instead of a variety of D

DebugInfo: Add metadata support for disabling DWARF pub sections

In cases where the debugger load time is a worthwhile tradeoff (or less
costly - such as loading from a DWP instead of a variety of DWOs
(possibly over a high-latency/distributed filesystem)) against object
file size, it can be reasonable to disable pubnames and corresponding
gdb-index creation in the linker.

A backend-flag version of this was implemented for NVPTX in
D44385/r327994 - which was fine for NVPTX which wouldn't mix-and-match
CUs. Now that it's going to be a user-facing option (likely powered by
"-gno-pubnames", the same as GCC) it should be encoded in the
DICompileUnit so it can vary per-CU.

After this, likely the NVPTX support should be migrated to the metadata
& the previous flag implementation should be removed.

Reviewers: aprantl

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

llvm-svn: 339939

show more ...

[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.

In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
nam

[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.

In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is

!DILabel(scope: !1, name: "foo", file: !2, line: 3)

We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is

llvm.dbg.label(metadata !1)

It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.

We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.

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

Patch by Hsiangkai Wang.

llvm-svn: 331841

show more ...

IR: Represent -ggnu-pubnames with a flag on the DICompileUnit.

This allows the flag to be persisted through to LTO.

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

llvm-svn: 313078

llvm-dwarfdump: Make -brief the default and add a -verbose option instead.

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

llvm-svn: 312972