Drodzy użytkownicy #Gentoo,
Zbliżamy się do wydania #LLVM 17.0.0. Wersje RC są już w ::gentoo, zamaskowane brakiem słów kluczowych. Będziemy wdzięczni za testowanie! W tym celu wykorzystać można poniższy fragment package.accept_keywords:
```
=dev-ml/llvm-ocaml-17.0.0_rc* **
=dev-python/lit-17.0.0_rc* **
=dev-util/lldb-17.0.0_rc* **
=dev-python/clang-python-17.0.0_rc* **
=sys-devel/clang-17.0.0_rc* **
=sys-devel/clang-common-17.0.0_rc* **
=sys-devel/clang-runtime-17.0.0_rc* **
=sys-devel/lld-17.0.0_rc* **
=sys-devel/llvm-17.0.0_rc* **
=sys-devel/llvm-common-17.0.0_rc* **
=sys-libs/compiler-rt-17.0.0_rc* **
=sys-libs/compiler-rt-sanitizers-17.0.0_rc* **
=sys-libs/libcxx-17.0.0_rc* **
=sys-libs/libcxxabi-17.0.0_rc* **
=sys-libs/libcxxrt-17.0.0_rc* **
=sys-libs/libomp-17.0.0_rc* **
=sys-libs/llvm-libunwind-17.0.0_rc* **
=dev-libs/libclc-17.0.0_rc* **
=dev-libs/mlir-17.0.0_rc* **
~sys-devel/llvmgold-17 **
~sys-devel/clang-toolchain-symlinks-17 **
~sys-devel/lld-toolchain-symlinks-17 **
~sys-devel/llvm-toolchain-symlinks-17 **
```
Wrzuciłem też pierwsze tygodniowe migawki 18.x (czyli głównej gąłęzi git). Dla tej wersji można użyć poniższego fragmentu:
```
=dev-ml/llvm-ocaml-18.0.0_pre* **
=dev-python/lit-18.0.0_pre* **
=dev-util/lldb-18.0.0_pre* **
=dev-python/clang-python-18.0.0_pre* **
=sys-devel/clang-18.0.0_pre* **
=sys-devel/clang-common-18.0.0_pre* **
=sys-devel/clang-runtime-18.0.0_pre* **
=sys-devel/lld-18.0.0_pre* **
=sys-devel/llvm-18.0.0_pre* **
=sys-devel/llvm-common-18.0.0_pre* **
=sys-libs/compiler-rt-18.0.0_pre* **
=sys-libs/compiler-rt-sanitizers-18.0.0_pre* **
=sys-libs/libcxx-18.0.0_pre* **
=sys-libs/libcxxabi-18.0.0_pre* **
=sys-libs/libcxxrt-18.0.0_pre* **
=sys-libs/libomp-18.0.0_pre* **
=sys-libs/llvm-libunwind-18.0.0_pre* **
=dev-libs/libclc-18.0.0_pre* **
=dev-libs/mlir-18.0.0_pre* **
~sys-devel/llvmgold-18 **
~sys-devel/clang-toolchain-symlinks-18 **
~sys-devel/lld-toolchain-symlinks-18 **
~sys-devel/llvm-toolchain-symlinks-18 **
```
#lldb #lld #clang #llvm #gentoo
I was interested in what #debugging tools for #rustlang could be used, so I've done research on this topic.
Initially, my aim was to pick up a tool for Emacs, but -at this stage at least- it all ended up with introducing self into #LLDB / #GDB world.
(I've still saved useful Emacs references for a possible practical dig-in later on.)
Anyway, the current results are wrapped up in the following post:
#debugging #rustlang #lldb #gdb
Does anyone have any clue why attaching to a process with #llvm's #lldb causes the process's stdin to close?
Here's an asciinema recording which demonstrates the issue: https://asciinema.org/a/tWu7v2RIR1PWSs8oCe789xMDm
#llvm #lldb #c #cpp #macos #macdev #debugging
Honestly, I'm not thinking positively of my past "commercial" work. Even these that weren't purely for someone's greed/vanity.
I mean, I'm really grateful for the opportunity to work on #LLDB and I'm sure this helped some people.
But still, I can't help thinking that #LLVM is about a few corporations figuring out they can outsource toolchain dev to #OpenSource and just hire a few strategic devs to protect their interest. No offense to the contributors.
#lldb #llvm #opensource #anticapitalism
Just added a script to Ghidra to build the lldb bindings from a brew install. Hopefully this will make it a little easier to use lldb and Ghidra together! 🐉👩💻
You can't do this on Friday
(lldb) po originalRequest
error: expression failed to parse:
warning: <EXPR>:11:7: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
After fixing a #Clang test failure and an #LLDB build failure, a new #LLVM snapshot has finally landed. I've also hit an MSAN test failure but sanitizers are scary and it seems to affect 6.1.x kernels only, so I've only reported it for the brave heroes to deal with: https://github.com/llvm/llvm-project/issues/59717
Wait... realgud + realgud-lldb = no fiddling with json files or editing templates? Am I missing something? Because that would be a huge QoL improvement for me.
#emacs #debugging #realgud #lldb
#emacs #debugging #realgud #lldb
Learned a new little #xcode #lldb trick: reading values directly from memory locations (using e.g. the stack pointer as the base). E.g.
$ memory read --format u --size 4 --count 1
I guess this is not super useful day-to-day, but when debugging argument passing via stack, it was super helpful to figure out where the Swift compiler has placed the values.
So, I wrote a LLDB plugin called Polar that queries @OpenAI davinci-003 and explains the disassembly of the frame. Will add this http://Lisa.py later, but now you can find the code for Polar here and try it out:
If you are using Node.js, take a look at the `llnode` plug-in, allowing JavaScript stack frames, objects and source code inspection from the LLDB debugger.
https://github.com/nodejs/llnode
#NodeJS #llnode #lldb #JavaScript #Debugger
#nodejs #llnode #lldb #javascript #debugger
If you are using Node.js, take a look at the `llnode` plug-in, allowing JavaScript stack frames, objects and source code inspection from the LLDB debugger.
https://github.com/nodejs/llnode
#NodeJS #llnode #lldb #JavaScript #Debugger
#lldb #nodejs #javascript #llnode #debugger
If you are using Node.js, take a look at the `llnode` plug-in, allowing JavaScript stack frames, objects and source code inspection from the LLDB debugger.
https://github.com/nodejs/llnode
#NodeJS #llnode #lldb #JavaScript #Debugger
#nodejs #llnode #lldb #javascript #debugger
If you are using Node.js, take a look at the `llnode` plug-in, allowing JavaScript stack frames, objects and source code inspection from the LLDB debugger.
https://github.com/nodejs/llnode
#NodeJS #llnode #lldb #JavaScript #Debugger
#nodejs #llnode #lldb #javascript #debugger