<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/llvm.git/lldb/include, branch EmptyLineAfterFunctionDefinition</title>
<subtitle>github.com: llvm/llvm-project.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/'/>
<entry>
<title>Revert "[NFC] Refactor symbol table parsing."</title>
<updated>2021-11-18T02:07:28+00:00</updated>
<author>
<name>Greg Clayton</name>
<email>gclayton@fb.com</email>
</author>
<published>2021-11-18T02:07:28+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=a68ccda203aad2cc4fd386d5e893237f09fa1ffb'/>
<id>a68ccda203aad2cc4fd386d5e893237f09fa1ffb</id>
<content type='text'>
This reverts commit 951b107eedab1829f18049443f03339dbb0db165.

Buildbots were failing, there is a deadlock in /Users/gclayton/Documents/src/llvm/clean/llvm-project/lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s when ELF files try to relocate things.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 951b107eedab1829f18049443f03339dbb0db165.

Buildbots were failing, there is a deadlock in /Users/gclayton/Documents/src/llvm/clean/llvm-project/lldb/test/Shell/SymbolFile/DWARF/DW_AT_range-DW_FORM_sec_offset.s when ELF files try to relocate things.
</pre>
</div>
</content>
</entry>
<entry>
<title>[NFC] Refactor symbol table parsing.</title>
<updated>2021-11-17T23:14:01+00:00</updated>
<author>
<name>Greg Clayton</name>
<email>gclayton@fb.com</email>
</author>
<published>2021-11-16T05:02:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=951b107eedab1829f18049443f03339dbb0db165'/>
<id>951b107eedab1829f18049443f03339dbb0db165</id>
<content type='text'>
Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &amp;symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once.

Differential Revision: https://reviews.llvm.org/D113965
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Symbol table parsing has evolved over the years and many plug-ins contained duplicate code in the ObjectFile::GetSymtab() that used to be pure virtual. With this change, the "Symbtab *ObjectFile::GetSymtab()" is no longer virtual and will end up calling a new "void ObjectFile::ParseSymtab(Symtab &amp;symtab)" pure virtual function to actually do the parsing. This helps centralize the code for parsing the symbol table and allows the ObjectFile base class to do all of the common work, like taking the necessary locks and creating the symbol table object itself. Plug-ins now just need to parse when they are asked to parse as the ParseSymtab function will only get called once.

Differential Revision: https://reviews.llvm.org/D113965
</pre>
</div>
</content>
</entry>
<entry>
<title>[llvm] Add a SFINAE template parameter to DenseMapInfo</title>
<updated>2021-11-16T18:54:14+00:00</updated>
<author>
<name>River Riddle</name>
<email>riddleriver@gmail.com</email>
</author>
<published>2021-11-16T17:59:45+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=4c484f11d355e4293f7b245a9330f0a1e89630ac'/>
<id>4c484f11d355e4293f7b245a9330f0a1e89630ac</id>
<content type='text'>
This allows for using SFINAE partial specialization for DenseMapInfo.
In MLIR, this is particularly useful as it will allow for defining partial
specializations that support all Attribute, Op, and Type classes without
needing to specialize DenseMapInfo for each individual class.

Differential Revision: https://reviews.llvm.org/D113641
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This allows for using SFINAE partial specialization for DenseMapInfo.
In MLIR, this is particularly useful as it will allow for defining partial
specializations that support all Attribute, Op, and Type classes without
needing to specialize DenseMapInfo for each individual class.

Differential Revision: https://reviews.llvm.org/D113641
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Refactor Platform::ResolveExecutable</title>
<updated>2021-11-16T11:52:51+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2021-11-09T15:32:57+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=098c01c132c8d14f08b847793afa045af5bb4522'/>
<id>098c01c132c8d14f08b847793afa045af5bb4522</id>
<content type='text'>
Module resolution is probably the most complex piece of lldb [citation
needed], with numerous levels of abstraction, each one implementing
various retry and fallback strategies.

It is also a very repetitive, with only small differences between
"host", "remote-and-connected" and "remote-but-not-(yet)-connected"
scenarios.

The goal of this patch (first in series) is to reduce the number of
abstractions, and deduplicate the code.

One of the reasons for this complexity is the tension between the desire
to offload the process of module resolution to the remote platform
instance (that's how most other platform methods work), and the desire
to keep it local to the outer platform class (its easier to subclass the
outer class, and it generally makes more sense).

This patch resolves that conflict in favour of doing everything in the
outer class. The gdb-remote (our only remote platform) implementation of
ResolveExecutable was not doing anything gdb-specific, and was rather
similar to the other implementations of that method (any divergence is
most likely the result of fixes not being applied everywhere rather than
intentional).

It does this by excising the remote platform out of the resolution
codepath. The gdb-remote implementation of ResolveExecutable is moved to
Platform::ResolveRemoteExecutable, and the (only) call site is
redirected to that. On its own, this does not achieve (much), but it
creates new opportunities for layer peeling and code sharing, since all
of the code now lives closer together.

Differential Revision: https://reviews.llvm.org/D113487
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Module resolution is probably the most complex piece of lldb [citation
needed], with numerous levels of abstraction, each one implementing
various retry and fallback strategies.

It is also a very repetitive, with only small differences between
"host", "remote-and-connected" and "remote-but-not-(yet)-connected"
scenarios.

The goal of this patch (first in series) is to reduce the number of
abstractions, and deduplicate the code.

One of the reasons for this complexity is the tension between the desire
to offload the process of module resolution to the remote platform
instance (that's how most other platform methods work), and the desire
to keep it local to the outer platform class (its easier to subclass the
outer class, and it generally makes more sense).

This patch resolves that conflict in favour of doing everything in the
outer class. The gdb-remote (our only remote platform) implementation of
ResolveExecutable was not doing anything gdb-specific, and was rather
similar to the other implementations of that method (any divergence is
most likely the result of fixes not being applied everywhere rather than
intentional).

It does this by excising the remote platform out of the resolution
codepath. The gdb-remote implementation of ResolveExecutable is moved to
Platform::ResolveRemoteExecutable, and the (only) call site is
redirected to that. On its own, this does not achieve (much), but it
creates new opportunities for layer peeling and code sharing, since all
of the code now lives closer together.

Differential Revision: https://reviews.llvm.org/D113487
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Simplify specifying of platform supported architectures</title>
<updated>2021-11-16T10:43:48+00:00</updated>
<author>
<name>Pavel Labath</name>
<email>pavel@labath.sk</email>
</author>
<published>2021-11-10T16:44:37+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=669e57ebd1a7137aba7aab47d9d4dd67e1b0b9a0'/>
<id>669e57ebd1a7137aba7aab47d9d4dd67e1b0b9a0</id>
<content type='text'>
The GetSupportedArchitectureAtIndex pattern forces the use of
complicated patterns in both the implementations of the function and in
the various callers.

This patch creates a new method (GetSupportedArchitectures), which
returns a list (vector) of architectures. The
GetSupportedArchitectureAtIndex is kept in order to enable incremental
rollout. Base Platform class contains implementations of both of these
methods, using the other method as the source of truth. Platforms
without infinite stacks should implement at least one of them.

This patch also ports Linux, FreeBSD and NetBSD platforms to the new
API. A new helper function (CreateArchList) is added to simplify the
common task of creating a list of ArchSpecs with the same OS but
different architectures.

Differential Revision: https://reviews.llvm.org/D113608
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The GetSupportedArchitectureAtIndex pattern forces the use of
complicated patterns in both the implementations of the function and in
the various callers.

This patch creates a new method (GetSupportedArchitectures), which
returns a list (vector) of architectures. The
GetSupportedArchitectureAtIndex is kept in order to enable incremental
rollout. Base Platform class contains implementations of both of these
methods, using the other method as the source of truth. Platforms
without infinite stacks should implement at least one of them.

This patch also ports Linux, FreeBSD and NetBSD platforms to the new
API. A new helper function (CreateArchList) is added to simplify the
common task of creating a list of ArchSpecs with the same OS but
different architectures.

Differential Revision: https://reviews.llvm.org/D113608
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Delete commented out code in AddressRange</title>
<updated>2021-11-11T23:42:27+00:00</updated>
<author>
<name>Alex Langford</name>
<email>apl@fb.com</email>
</author>
<published>2021-11-11T23:41:40+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=ac33e65d2169260364e3e92fed2ba81c58d5ce33'/>
<id>ac33e65d2169260364e3e92fed2ba81c58d5ce33</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Inclusive Language: rename master plan to controlling plan</title>
<updated>2021-11-11T21:04:44+00:00</updated>
<author>
<name>Quinn Pham</name>
<email>Quinn.Pham@ibm.com</email>
</author>
<published>2021-11-02T13:58:19+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=04cbfa950e0221ac334f802407a9b766df33eee5'/>
<id>04cbfa950e0221ac334f802407a9b766df33eee5</id>
<content type='text'>
[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

Reviewed By: jingham

Differential Revision: https://reviews.llvm.org/D113019
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

Reviewed By: jingham

Differential Revision: https://reviews.llvm.org/D113019
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Remove no longer valid comment for TypeSystem::SetSymbolFile</title>
<updated>2021-11-11T11:39:54+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2021-11-11T11:39:54+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=2a0e77362e3ac1f4de1290640ad1122f9d4e208b'/>
<id>2a0e77362e3ac1f4de1290640ad1122f9d4e208b</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][AArch64] Add UnwindPlan for Linux sigreturn</title>
<updated>2021-11-11T11:32:06+00:00</updated>
<author>
<name>David Spickett</name>
<email>david.spickett@linaro.org</email>
</author>
<published>2021-10-08T10:44:23+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=9db2541d4c30100d7ccc6cc9db717df102b302d9'/>
<id>9db2541d4c30100d7ccc6cc9db717df102b302d9</id>
<content type='text'>
This adds a specific unwind plan for AArch64 Linux sigreturn frames.
Previously we assumed that the fp would be valid here but it is not.

https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/vdso/sigreturn.S

On Ubuntu Bionic it happened to point to an old frame info which meant
you got what looked like a correct backtrace. On Focal, the info is
completely invalid. (probably due to some code shuffling in libc)

This adds an UnwindPlan that knows that the sp in a sigreturn frame
points to an rt_sigframe from which we can offset to get saved
sp and pc values to backtrace correctly.

Based on LibUnwind's change: https://reviews.llvm.org/D90898

A new test is added that sets all compares the frames from the initial
signal catch to the handler break. Ensuring that the stack/frame pointer,
function name and register values match.
(this test is AArch64 Linux specific because it's the only one
with a specific unwind plan for this situation)

Fixes https://bugs.llvm.org/show_bug.cgi?id=52165

Reviewed By: omjavaid, labath

Differential Revision: https://reviews.llvm.org/D112069
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This adds a specific unwind plan for AArch64 Linux sigreturn frames.
Previously we assumed that the fp would be valid here but it is not.

https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/vdso/sigreturn.S

On Ubuntu Bionic it happened to point to an old frame info which meant
you got what looked like a correct backtrace. On Focal, the info is
completely invalid. (probably due to some code shuffling in libc)

This adds an UnwindPlan that knows that the sp in a sigreturn frame
points to an rt_sigframe from which we can offset to get saved
sp and pc values to backtrace correctly.

Based on LibUnwind's change: https://reviews.llvm.org/D90898

A new test is added that sets all compares the frames from the initial
signal catch to the handler break. Ensuring that the stack/frame pointer,
function name and register values match.
(this test is AArch64 Linux specific because it's the only one
with a specific unwind plan for this situation)

Fixes https://bugs.llvm.org/show_bug.cgi?id=52165

Reviewed By: omjavaid, labath

Differential Revision: https://reviews.llvm.org/D112069
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Add support for demangling D symbols</title>
<updated>2021-11-11T10:11:21+00:00</updated>
<author>
<name>Luís Ferreira</name>
<email>contact@lsferreira.net</email>
</author>
<published>2021-11-11T09:42:14+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/llvm.git/commit/?id=96a7359908397d8db3ac6f8e10fb9f6dc5756a44'/>
<id>96a7359908397d8db3ac6f8e10fb9f6dc5756a44</id>
<content type='text'>
This is part of https://github.com/dlang/projects/issues/81 .

This patch enables support for D programming language demangler by using a
pretty printed stacktrace with demangled D symbols, when present.

Signed-off-by: Luís Ferreira &lt;contact@lsferreira.net&gt;

Reviewed By: JDevlieghere, teemperor

Differential Revision: https://reviews.llvm.org/D110578
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is part of https://github.com/dlang/projects/issues/81 .

This patch enables support for D programming language demangler by using a
pretty printed stacktrace with demangled D symbols, when present.

Signed-off-by: Luís Ferreira &lt;contact@lsferreira.net&gt;

Reviewed By: JDevlieghere, teemperor

Differential Revision: https://reviews.llvm.org/D110578
</pre>
</div>
</content>
</entry>
</feed>
