<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/lldb/source/API/SBLineEntry.cpp, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[lldb] fix set SBLineEntryColumn (#130435)</title>
<updated>2025-03-10T16:10:23+00:00</updated>
<author>
<name>Ebuka Ezike</name>
<email>57949090+da-viper@users.noreply.github.com</email>
</author>
<published>2025-03-10T16:10:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e9b2eddd5be753e72010da8a4333df8195e1641c'/>
<id>e9b2eddd5be753e72010da8a4333df8195e1641c</id>
<content type='text'>
Calling the public API `SBLineEntry::SetColumn()` sets the row instead
of the column.

This probably should be backported as it has been since version 3.4.

---------

Co-authored-by: Jonas Devlieghere &lt;jonas@devlieghere.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Calling the public API `SBLineEntry::SetColumn()` sets the row instead
of the column.

This probably should be backported as it has been since version 3.4.

---------

Co-authored-by: Jonas Devlieghere &lt;jonas@devlieghere.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>Initial step in targets DAP support  (#86623)</title>
<updated>2024-04-25T18:49:10+00:00</updated>
<author>
<name>jeffreytan81</name>
<email>jeffreytan@meta.com</email>
</author>
<published>2024-04-25T18:49:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=2f2e31c3c980407b2660b4f5d10e7cdb3fa79138'/>
<id>2f2e31c3c980407b2660b4f5d10e7cdb3fa79138</id>
<content type='text'>
This patch provides the initial implementation for the "Step Into
Specific/Step In Targets" feature in VSCode DAP.

The implementation disassembles all the call instructions in step range
and try to resolve operand name (assuming one operand) using debug info.
Later, the call target function name is chosen by end user and specified
in the StepInto() API call.

It is v1 because of using the existing step in target function name API.
This implementation has several limitations:
* Won't for indirect/virtual function call -- in most cases, our
disassembler won't be able to solve the indirect call target
address/name.
* Won't work for target function without debug info -- if the target
function has symbol but not debug info, the existing
ThreadPlanStepInRange won't stop.
* Relying on function names can be fragile -- if there is some middle
glue/thunk code, our disassembler can only resolve the glue/thunk code's
name not the real target function name. It can be fragile to depend
compiler/linker emits the same names for both.
* Does not support step into raw address call sites -- it is a valid
scenario that in Visual Studio debugger, user can explicitly choose a
raw address to step into which land in the function without debug
info/symbol, then choose UI to load the debug info on-demand for that
module/frame to continue exploring.

A more reliable design could be extending the ThreadPlanStepInRange to
support step in based on call-site instruction offset/PC which I will
propose in next iteration.

---------

Co-authored-by: jeffreytan81 &lt;jeffreytan@fb.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch provides the initial implementation for the "Step Into
Specific/Step In Targets" feature in VSCode DAP.

The implementation disassembles all the call instructions in step range
and try to resolve operand name (assuming one operand) using debug info.
Later, the call target function name is chosen by end user and specified
in the StepInto() API call.

It is v1 because of using the existing step in target function name API.
This implementation has several limitations:
* Won't for indirect/virtual function call -- in most cases, our
disassembler won't be able to solve the indirect call target
address/name.
* Won't work for target function without debug info -- if the target
function has symbol but not debug info, the existing
ThreadPlanStepInRange won't stop.
* Relying on function names can be fragile -- if there is some middle
glue/thunk code, our disassembler can only resolve the glue/thunk code's
name not the real target function name. It can be fragile to depend
compiler/linker emits the same names for both.
* Does not support step into raw address call sites -- it is a valid
scenario that in Visual Studio debugger, user can explicitly choose a
raw address to step into which land in the function without debug
info/symbol, then choose UI to load the debug info on-demand for that
module/frame to continue exploring.

A more reliable design could be extending the ThreadPlanStepInRange to
support step in based on call-site instruction offset/PC which I will
propose in next iteration.

---------

Co-authored-by: jeffreytan81 &lt;jeffreytan@fb.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Reland: Store SupportFile in FileEntry (NFC) (#85892)</title>
<updated>2024-03-21T15:40:08+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2024-03-21T15:40:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=556fe5f290ea88dcbb7ced16b0f057dcebce1fd0'/>
<id>556fe5f290ea88dcbb7ced16b0f057dcebce1fd0</id>
<content type='text'>
This is another step towards supporting DWARF5 checksums and inline
source code in LLDB. This is a reland of #85468 but without the
functional change of storing the support file from the line table (yet).</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is another step towards supporting DWARF5 checksums and inline
source code in LLDB. This is a reland of #85468 but without the
functional change of storing the support file from the line table (yet).</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "[lldb] Store SupportFile in FileEntry (NFC)" (#85885)</title>
<updated>2024-03-20T00:48:46+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2024-03-20T00:48:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a289f66efd638c2af14cdb88968e4eaeea0c0605'/>
<id>a289f66efd638c2af14cdb88968e4eaeea0c0605</id>
<content type='text'>
Reverts llvm/llvm-project#85468 because @slackito reports this broke
stepping in one of their tests [1] and this patch was meant to be NFC.

[1]
https://github.com/llvm/llvm-project/commit/d5a277d309e92b1d3e493da6036cffdf815105b1#commitcomment-139991120</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Reverts llvm/llvm-project#85468 because @slackito reports this broke
stepping in one of their tests [1] and this patch was meant to be NFC.

[1]
https://github.com/llvm/llvm-project/commit/d5a277d309e92b1d3e493da6036cffdf815105b1#commitcomment-139991120</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Store SupportFile in FileEntry (NFC) (#85468)</title>
<updated>2024-03-15T22:03:54+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2024-03-15T22:03:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d5a277d309e92b1d3e493da6036cffdf815105b1'/>
<id>d5a277d309e92b1d3e493da6036cffdf815105b1</id>
<content type='text'>
This is another step towards supporting DWARF5 checksums and inline
source code in LLDB.</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is another step towards supporting DWARF5 checksums and inline
source code in LLDB.</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Decouple instrumentation from the reproducers</title>
<updated>2022-01-21T02:06:14+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2022-01-19T19:38:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1755f5b1d7b7871672abdf0fde5ccd091b8dbc04'/>
<id>1755f5b1d7b7871672abdf0fde5ccd091b8dbc04</id>
<content type='text'>
Remove the last remaining references to the reproducers from the
instrumentation. This patch renames the relevant files and macros.

Differential revision: https://reviews.llvm.org/D117712
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Remove the last remaining references to the reproducers from the
instrumentation. This patch renames the relevant files and macros.

Differential revision: https://reviews.llvm.org/D117712
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Remove LLDB_RECORD_RESULT macro</title>
<updated>2022-01-10T06:54:17+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2022-01-10T06:54:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d232abc33b707d2da8ca4e4c84d8287ce0e1a47a'/>
<id>d232abc33b707d2da8ca4e4c84d8287ce0e1a47a</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb] Remove reproducer instrumentation</title>
<updated>2022-01-10T05:40:55+00:00</updated>
<author>
<name>Jonas Devlieghere</name>
<email>jonas@devlieghere.com</email>
</author>
<published>2022-01-08T00:26:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=d51402ac6b802dbc17402135067d302853b34252'/>
<id>d51402ac6b802dbc17402135067d302853b34252</id>
<content type='text'>
This patch removes most of the reproducer instrumentation. It keeps
around the LLDB_RECORD_* macros for logging. See [1] for more details.

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

Differential revision: https://reviews.llvm.org/D116847
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch removes most of the reproducer instrumentation. It keeps
around the LLDB_RECORD_* macros for logging. See [1] for more details.

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

Differential revision: https://reviews.llvm.org/D116847
</pre>
</div>
</content>
</entry>
<entry>
<title>[API] Remove redundant member initialization (NFC)</title>
<updated>2022-01-03T06:44:16+00:00</updated>
<author>
<name>Kazu Hirata</name>
<email>kazu@google.com</email>
</author>
<published>2022-01-03T06:44:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=a3436f7340cb5bdb9dddf2b6b3e72ca6cf9f7e22'/>
<id>a3436f7340cb5bdb9dddf2b6b3e72ca6cf9f7e22</id>
<content type='text'>
Identified with readability-redundant-member-init.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Identified with readability-redundant-member-init.
</pre>
</div>
</content>
</entry>
<entry>
<title>[lldb][NFC] Use C++ versions of the deprecated C standard library headers</title>
<updated>2021-05-26T10:46:12+00:00</updated>
<author>
<name>Raphael Isemann</name>
<email>teemperor@gmail.com</email>
</author>
<published>2021-05-26T10:19:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=76e47d4887f456878c0e2f20ebfae36267006cd7'/>
<id>76e47d4887f456878c0e2f20ebfae36267006cd7</id>
<content type='text'>
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D103084
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

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