LLDB 20 Request For Release Notes!

Subprojects LLDB
1

Hi all, according to the schedule we are about 2 weeks away from the creation of the llvm 20 branch.

I know we’ve all done a lot of work since lldb 19, and it’s easy for things to get forgotten. So I have started the release note party by documenting the impending Python requirements for LLDB 21.

I also went through all the commits since the llvmorg-20-init tag until today, and noted anything I thought might warrant a release note. Some might have been reverted, some might not be finished, I leave it up to you, the PR authors, to decide.

For reference here are the current release notes and here are the ones for 19.1.0. The file you need to edit is here (and it’s Markdown now, much easier!).

Here’s my list of interesting commits, and I’ve tagged the authors and/or maintainer who would know best to write release notes for them. If I’ve left something out, it’s not because I deemed it insignificant, I did my best to pick neutrally, but I’m not perfect.

This is a bit spammy, but the alternative was emailing you all individually, and this thread gives us a chance to consolidate some of the entries.

Commands

39c23a31d2ab Revert “[lldb/Commands] Add scripting template list command with auto discovery” (#100273)

@mib I know this is the revert PR but I think it got relanded.

1250a1db1a37 [lldb] Update dwim-print to support limited variable expression paths (#117452)

@kastiglione do you have things to add about dwim-print or the expression language?

04b443e77845 Add the ability to define custom completers to the parsed_cmd template. (#109062)

This has been noted.

cc5c526c80a4 [lldb] Fix and speedup the memory find command (#104193)

@labath maybe you don’t need to mention the “it was broken” part :slight_smile: but the speedup seems worth adding.

LoongArch (DONE)

1c8fca82a0f4 [lldb][LoongArch] Function calls support in lldb expressions

6c4e70fcbbb6 [lldb][Process] Introduce LoongArch64 hw break/watchpoint support

@wangleiat do you want to add a note saying what LoongArch features were implemented? (remember that the SIMD stuff is about to go in)

RISC-V (DONE)

660e34fd38c3 [lldb][RISCV] Support optionally disabled FPR for riscv64 (#104547)

(author not on Discourse, will comment on PR)

87121403e251 [lldb][RISCV] function calls support in lldb expressions (#99336)

(author not on Discourse, will comment on PR)

MacOS

46e782300765 [lldb][debugserver] Read/write SME registers on arm64 (#119171)

Given that the MacOS release required to use this is likely not going to be public, I think we leave this out, does that make sense to you @jasonmolenda ? (though it is cool work :slight_smile: )

lldb-dap

ff5953804ea5 [lldb-dap] Support finding the lldb-dap binary (#118547)

Decided not to mention this one since it only applies to the plugin.

4f48a81a620b [lldb-dap] Support column breakpoints (#113787)

Currently reverted.

2011cbcd8410 [lldb-dap] Add feature to remember last non-empty expression. (#107485)

3acb1eac5eb6 [lldb-dap] Support inspecting memory (#104317)

89c27d6b07dd [lldb-dap] Enabling instruction breakpoint support to lldb-dap. (#105278)

@clayborg / @wallace do either of you want to summarise this? I think we have enough for an lldb-dap sub-section.

Minidump (DONE)

e9c8f75d45ab [LLDB][Minidump] Have Minidumps save off and properly read TLS data (#109477)

5033ea73bb01 [LLDB][Minidump] Add breakpoint stop reasons to the minidump. (#108448)

492683527eda [LLDB][Minidump] Support minidumps where there are multiple exception streams (#97470)

(same author, not on discourse, will comment on a PR instead)

Core Files (DONE)

d8ebb08a8973 [lldb] Have disassembler show load addresses when using a core file (#115453)

0a7242959f5d [LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (#110065)

@labath could you write this/these up?

SBSaveCore (DONE)

3e4af616334e [LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (#100443)

d4d4e7791811 [LLDB] Reappply SBSaveCore AddMemoryList (#107159)

(also from Minidump author…)

Interpreter

1e131ddfa8f1 [lldb/Interpreter] Introduce ScriptedStopHook{,Python}Interface & make use of it (#105449)

@mib not sure if this is user facing or not.

lldb-server (DONE)

82ee31f75ac1 [lldb] Updated lldb-server to spawn the child process and share socket (#101283)

2e89312419c5 [lldb] Removed gdbserver ports map from lldb-server (#104238)

(author not on Discourse, will comment on PR)

Logging (DONE)

c77b10746160 [lldb] Introduce an always-on system log category/channel (#108495)

@JDevlieghere not sure whether this really does anything yet, and even so, maybe it’s best that we don’t advertise it. Best leave it out?

Breakpoints (DONE)

f14743794587 Add the ability to break on call-site locations, improve inline stepping (#112939)

@jingham significant enough to note?

2 Likes
2

Yes, I don’t think this is worth mentioning, especially since we decided to keep this macOS-only for now.

This change only affects the VSCode plugin (i.e. not the lldb-dap binary) and has already been published in the Marketplace. So I’m not sure if it’s worth mentioning as part of the LLVM release.

PS: Thanks for putting this together! It’s easy to forget how much awesome work has gone into a release. This is a great reminder of everything that’s been going on.

3

On the clang frontend, we require a release note with each PR. This really prevents us from having this scramble every release. This is a approach LLDB may want to consider for the future.

1 Like
4

Certainly we could. Did you ever write down any guidelines for that?

Edit: Also I presume you mean that you consider a release note for each PR? There must be some that don’t warrant one.

5

This commit got reverted. I did not find time to revisit it, yet. For the time being, let’s not mention this in the release notes

6

I believe we rely on LLVM Developer Policy — LLVM 20.0.0git documentation

and we just ask for one during code review if someone does not apply one and we believe they should.

Not all PR require a release note e.g. you are fixing a bug to a feature you just landed.

1 Like
7

Might be worth mentioning.

It used to be that if you had an inlined function as the only statement in a source line, then you would not be able to put a breakpoint on that source line, it would be moved to the next one and you would miss the execution of that line’s code altogether. With this change the breakpoint will get set before the inlined code is executed.

1 Like
8

I added the mention of inlined call site support and using the built-in command parser for Python commands.

9

Thanks!

10

[llvm][Docs] Add release note about LLDB core file improvements by labath · Pull Request #123062 · llvm/llvm-project · GitHub (I’ve put both into the same note)

11

In theory the 20 branch will be created today. Everything obvious apart from lldb-dap is in. I was going to write that up myself but on closer inspection, I don’t know it well enough.

Thanks to everyone who added release notes!

Going forward I will be thinking more during review whether a release note should be added, I suggest we all do.

(not that missing something is the end of the world, but it is nice to show work has been done :slight_smile: )

@clayborg / @wallace you can always send a PR for the release branch if you want to add notes for lldb-dap.

12

I tried following this guidance in my latest pull request. Unfortunately, editing the LLVM release notes also triggers all the LLVM tests. Seems a bit wasteful, and also my PR is now red because BOLT had some hiccup.

Can we change the CI to not trigger the LLVM tests if I only change the release notes?

13

This will be somewhere in the workflows that trigger the jobs, but since we are between systems at the moment there might actually be 2 places to change it.

@boomanaiden154-1 might know.

14

Nothing to add, thank you for calling out that change.

15

Sorry for not seeing this for the past month. Apparently I did not check my notifications closely enough.

Currently anything within llvm/ that gets touched requires rebuilding and testing everything. I would be fine with adding a carve out for specific file extensions in project-specific docs directories. Currently only one shell script needs to be modified to achieve that (in the top level of .ci). I will try and put up a patch by the end of next week, but more than happy to review if someone else is interested in getting that done.

1 Like