|
lldb is pretty solidly the slowest and least reliable debugger i've ever had the misfortune of using. when apple first started shipping it i assumed it was bad because it was just being shipped as soon as it was kinda maybe close to ready, but it hasn't gotten any better since then
|
#
?
Oct 25, 2019 18:58
|
|
|
|
| # ? Apr 19, 2024 11:27 |
|
|
dtrace used to be amazing but it's bitrotted hard. you have to turn off SIP to do anything interesting and even then a ton of stuff is broken on recent versions of macos.
|
|
#
?
Oct 25, 2019 18:59
|
|
|
lldb is bad. even with a huge amount of debug info the compiler now emits it still does a terrible job of getting local variable values. and it’s way too verbose for a command line interface, mostly because it was designed as a backend tool for Xcode, not for direct human interaction.
|
|
#
?
Oct 25, 2019 21:17
|
|
|
the crazy interface is not because it was designed to work as a library for xcode. they actually thought it was better this way, and now it’s hard to do anything about it the interface is very tweakable, though
|
|
#
?
Oct 26, 2019 04:23
|
|
|
rjmccall posted:the interface is very twerkable, though
|
|
#
?
Oct 26, 2019 04:28
|
|
|
ladies love debugging
|
|
#
?
Oct 26, 2019 04:46
|
|
|
gdb's command-line interface is a giant mess so i do appreciate that lldb tried to come up with something more consistent and understandable. they just didn't do a very good job of it, unfortunately. the interface is a a pretty small problem compared to things like it having a broken implementation of step over/out and having a braindead debug visualizer api that inherently results in it regularly taking multiple seconds to update xcode's watch window.
|
|
#
?
Oct 26, 2019 07:52
|
|
|
lldb is ok if you use it with a gui (like a vscode addon) although we use it at work from inside visual studio on one of our target platforms and stepping is slow as hell, and for once I dont think it's visual studios fault
|
|
#
?
Oct 26, 2019 11:36
|
|
|
The Management posted:lldb is terrible. maybe its because I used it first but I like it more than gdb.
|
|
#
?
Oct 26, 2019 16:34
|
|
|
is lldb the thing that makes it so that xcode never shows you actual values of symbols you hover your mouse over?
|
|
#
?
Oct 26, 2019 16:37
|
|
|
java remote debugging is some (slow) magical poo poo
|
|
#
?
Oct 26, 2019 16:49
|
|
|
akadajet posted:is lldb the thing that makes it so that xcode never shows you actual values of symbols you hover your mouse over? it works fine in clion, so i imagine that it's just xcode being lovely
|
|
#
?
Oct 26, 2019 17:34
|
|
|
akadajet posted:is lldb the thing that makes it so that xcode never shows you actual values of symbols you hover your mouse over? yes.
|
|
#
?
Oct 26, 2019 18:43
|
|
|
now that rms is out of the picture i hope we get full llvm/lldb support in emacs or get gcc to have a sane intermediate format so that good things can be done with gcc and emacs i don't really care, i just want better c++ integration in emacs
|
|
#
?
Oct 26, 2019 20:00
|
|
|
Notorious b.s.d. posted:i hope we get full llvm/lldb support in emacs I've been growing my beard out but a sudden wave of insecurity just washed over me.
|
|
#
?
Oct 26, 2019 20:50
|
|
|
rms has been the sticking point on both fixing up gcc's intermediate format (which has historically been deliberately unuseable by outside tools) and integrating llvm support into emacs (because llvm isn't as fully free as gcc) i don't care which sticking point gets un-stuck, i have no real preference here, i just want c++ to not-suck in emacs
|
|
#
?
Oct 26, 2019 20:55
|
|
|
|
| # ? Apr 19, 2024 11:27 |
|
|
Jonny 290 posted:sir this is a wework
|
|
#
?
Oct 26, 2019 21:42
|
|
