[llvm-branch-commits] [lldb] release/19.x: [lldb] Move definition of SBSaveCoreOptions dtor out of header (#102539) (PR #102680)
https://github.com/clayborg approved this pull request. https://github.com/llvm/llvm-project/pull/102680 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [GSYM] Include end_sequence debug_line rows in Dwarf transform (PR #90535)
https://github.com/clayborg edited https://github.com/llvm/llvm-project/pull/90535 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [GSYM] Include end_sequence debug_line rows in Dwarf transform (PR #90535)
@@ -424,19 +439,13 @@ static void convertFunctionLineTable(OutputAggregator
&Out, CUInfo &CUI,
auto LastLE = FI.OptLineTable->last();
if (LastLE && LastLE->File == FileIdx && LastLE->Line == Row.Line)
continue;
+
// Only push a row if it isn't an end sequence. End sequence markers are
// included for the last address in a function or the last contiguous
// address in a sequence.
-if (Row.EndSequence) {
clayborg wrote:
We used to not break out on Row.EndSequence as it allows functions to have
discontiguous ranges. Not sure if that happens. I was assuming that if we asked
for the rows for a given address range we wouldn't get all entries if two
merged functions with different line table entries were found, but that
assumption might not be correct?
https://github.com/llvm/llvm-project/pull/90535
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [GSYM] Include end_sequence debug_line rows in Dwarf transform (PR #90535)
@@ -354,6 +357,18 @@ static void convertFunctionLineTable(OutputAggregator
&Out, CUInfo &CUI,
for (uint32_t RowIndex : RowVector) {
// Take file number and line/column from the row.
const DWARFDebugLine::Row &Row = CUI.LineTable->Rows[RowIndex];
+
+// TODO(avillega): With this conditional, functions folded by `icf`
+// optimizations will only include 1 of all the folded functions. There is
+// not a clear path forward to have the information of all folded functions
+// in gsym.
+if (Row.EndSequence) {
+ // End sequence markers are included for the last address
+ // in a function or the last contiguos address in a sequence.
+ break;
+}
+
+
clayborg wrote:
What if a function is split into two discontiguous ranges? This will lose the
line table information for any subsequent discontiguous ranges since we break
out of the loop here.
https://github.com/llvm/llvm-project/pull/90535
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [GSYM] Include end_sequence debug_line rows in Dwarf transform (PR #90535)
@@ -321,7 +321,10 @@ static void convertFunctionLineTable(OutputAggregator
&Out, CUInfo &CUI,
StartAddress, object::SectionedAddress::UndefSection};
- if (!CUI.LineTable->lookupAddressRange(SecAddress, RangeSize, RowVector)) {
+ // end_sequence markers can be located at RangeSize position,
+ // lookupAddressRange search up to RangeSize not inclusive, to include
+ // end_sequence markers it is necessary to lookup until RangeSize+1
+ if (!CUI.LineTable->lookupAddressRange(SecAddress, RangeSize + 1,
RowVector)) {
clayborg wrote:
If a line table has two functions that share the same address range within the
same line table, this call currently will return only matches from the first
sequence that contains an address. So we won't get all rows from all sequences
that match. I checked the
`DWARFDebugLine::LineTable::lookupAddressRangeImpl(...)` function to verify.
https://github.com/llvm/llvm-project/pull/90535
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [GSYM] Include end_sequence debug_line rows in Dwarf transform (PR #90535)
https://github.com/clayborg commented: Not sure this makes sense after checking the code for `DWARFDebugLine::LineTable::lookupAddressRangeImpl(...)`. If a line table has multiple sequences that contain an address, it will find the first sequence that contains the address and then return the rows for the function. What is the effect of this change on the test case? Does it change the final line table in the GSYM file? https://github.com/llvm/llvm-project/pull/90535 ___ llvm-branch-commits mailing list llvm-branch-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [GSYM] Include end_sequence debug_line rows in Dwarf transform (PR #90535)
@@ -424,19 +439,13 @@ static void convertFunctionLineTable(OutputAggregator
&Out, CUInfo &CUI,
auto LastLE = FI.OptLineTable->last();
if (LastLE && LastLE->File == FileIdx && LastLE->Line == Row.Line)
continue;
+
// Only push a row if it isn't an end sequence. End sequence markers are
// included for the last address in a function or the last contiguous
// address in a sequence.
-if (Row.EndSequence) {
clayborg wrote:
> I'm not quite following the collection of thoughts here, they seem disjoint
> to me, so trying to discuss:
>
> > We used to not break out on Row.EndSequence
>
> I don't understand the relationship between end_sequence and functions with
> discontiguous ranges - could you describe this connection in more detail?
If a `DW_TAG_subprogram` has N discontiguous ranges, we will create N
FunctionInfo objects, one for each range. We will request the line table
entries for each range in the `DW_TAG_subprogram`'s `DW_AT_ranges` attribute.
So if there are end sequences in there, we try to keep going. If there is an
end_sequence in the line table this is probably the indication of a bug in the
line tables.
>
> > as it allows functions to have discontiguous ranges.
>
> Agreed with @pogo59, I believe both Bolt and Propeller can create
> discontiguous address ranges for a function (but you'll see DW_AT_ranges on
> the subprogram)
Yes, and as I mention above, we create individual FunctionInfo objects for each
range and only request the line table entries for each individual range.
>
> > I was assuming that if we asked for the rows for a given address range we
> > wouldn't get all entries if two merged functions with different line table
> > entries were found, but that assumption might not be correct?
>
> Yeah, looking at the implementation of `lookupAddressRangeImpl` it finds a
> single sequence that starts closest to the start address, then adds all rows
> within that sequence that cover the range requested. So, no, it won't
> retrieve addresses/ranges from multiple sequences.
https://github.com/llvm/llvm-project/pull/90535
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
[llvm-branch-commits] [lldb] 3fca962 - [lldb-vscode] Make it possible to run vsce package
Author: Greg Clayton
Date: 2020-05-28T13:29:48-07:00
New Revision: 3fca962854050cd4af513a514f45596a0ae7a4f2
URL:
https://github.com/llvm/llvm-project/commit/3fca962854050cd4af513a514f45596a0ae7a4f2
DIFF:
https://github.com/llvm/llvm-project/commit/3fca962854050cd4af513a514f45596a0ae7a4f2.diff
LOG: [lldb-vscode] Make it possible to run vsce package
Summary:
Running `vsce package` to package lldb-vscode as an installable .vsix file
errors with:
```
ERROR Invalid publisher name 'llvm.org'. Expected the identifier of a
publisher, not its human-friendly name.
```
This patch fixes the publisher name and bumps a required dependency so that
`vsce package` succeeds.
Reviewers: clayborg
Reviewed By: clayborg
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80569
Added:
Modified:
lldb/tools/lldb-vscode/package.json
Removed:
diff --git a/lldb/tools/lldb-vscode/package.json
b/lldb/tools/lldb-vscode/package.json
index 1df16d0dfe35..f4408d3607d9 100644
--- a/lldb/tools/lldb-vscode/package.json
+++ b/lldb/tools/lldb-vscode/package.json
@@ -2,7 +2,8 @@
"name": "lldb-vscode",
"displayName": "LLDB native Debug stub",
"version": "0.1.0",
- "publisher": "llvm.org",
+ "publisher": "llvm",
+ "repository": "llvm.org",
"description": "Debug adapter for LLDB which uses a C++ tool to
interface directly with LLDB.",
"author": {
"name": "Greg Clayton",
@@ -16,7 +17,6 @@
"vscode": "^1.18.0",
"node": "^7.9.0"
},
- "icon": "images/lldb.png",
"categories": [
"Debuggers"
],
@@ -29,7 +29,7 @@
"vscode": "1.1.10",
"vscode-debugadapter-testsupport": "1.25.0",
"tslint": "5.8.0",
- "vsce": "1.35.0"
+ "vsce": "^1.36.3"
},
"contributes": {
"debuggers": [
@@ -70,7 +70,10 @@
"description":
"Path to the program to debug."
},
"args": {
- "type": [
"array", "string" ],
+ "type": [
+ "array",
+ "string"
+ ],
"description":
"Program arguments.",
"default": []
},
@@ -131,29 +134,29 @@
"description":
"Name of the execution platform to override value derived from the program
file."
},
"initCommands": {
- "type":
"array",
-
"description": "Initialization commands executed upon debugger startup.",
-
"default": []
+ "type": "array",
+ "description":
"Initialization commands executed upon debugger startup.",
+ "default": []
},
"preRunCommands": {
- "type":
"array",
-
"description": "Commands executed just before the program is launched.",
-
"default": []
+ "type": "array",
+ "description":
"Commands executed just before the program is launched.",
+ "default": []
},
"launchCommands": {
- "type":
"array",
-
"description": "Custom commands that are executed instead of launching a
pro
