4 ms·

LLVM has devolved into complete garbage in Xcode for large Swift projects. Slowless aside, at least half the time it won't display values for variables after hi

by dangwu 6y ago

LLVM has devolved into complete garbage in Xcode for large Swift projects. Slowless aside, at least half the time it won't display values for variables after hitting a breakpoint, and my team has to resort to using print statements to debug issues.

saagarjha 6y ago
That would be the LLDB Swift integration specifically.
jeffbee 6y ago
Perhaps you should try using JetBrains AppCode, from the company that employs the author of this article.
mmm_grayons 6y ago
That's probably a swift issue rather than LLVM. LLDB works great for me on C code.
bla3 6y ago
Given that it works reasonably well for rust and c++, maybe that's more a problem on the Xcode or Swift side?
MobiusHorizons 6y ago
Are you debugging optimized builds? I have definitely had variables be unavailable at debug time, due to optimization in C in lldb. I would guess that the same could be true for swift's integration.
- dman 6y ago
  Anecdotally gcc + gdb does release with debug info builds a lot better than clang + lldb. In general quality of debug info is one place I have had fewer issues with gcc/gdb than I have with clang/lldb.
- loeg 6y ago
  Clang loses a lot of information for values that are still available or computable in its optimization passes. It's not purely the values being completely lost to optimization. GCC continues to emit relatively better debuginfo at similar optimization levels. Samy Al Bahra has written and talked about this a couple of times over the years.
  - brandmeyer 6y ago
    I dunno, I see the same issue in GCC, even at -Og. Both compilers will aggressively mark variables dead and reuse their (memory, registers) as soon as possible. Just because its in scope, doesn't mean its still live.
    - loeg 6y ago
      Yes, scope and liveness are not exactly the same. No, that does not mean the scoped value cannot be restored cheaply. DWARF can express the value of a variable in terms of expressions that do computations on other registers and/or access memory; it does not have to be as simplistic as "this value lives in this register for some period of time." Clang (and to a lesser extent, GCC) fail to do that for non-live, in-scope registers much of the time. Clang in particular just loses that metadata in many optimization passes.

by dangwu 6y ago

saagarjha 6y ago

That would be the LLDB Swift integration specifically.

jeffbee 6y ago

Perhaps you should try using JetBrains AppCode, from the company that employs the author of this article.

mmm_grayons 6y ago

That's probably a swift issue rather than LLVM. LLDB works great for me on C code.

bla3 6y ago

Given that it works reasonably well for rust and c++, maybe that's more a problem on the Xcode or Swift side?

MobiusHorizons 6y ago

Are you debugging optimized builds? I have definitely had variables be unavailable at debug time, due to optimization in C in lldb. I would guess that the same could be true for swift's integration.

dman 6y ago
Anecdotally gcc + gdb does release with debug info builds a lot better than clang + lldb. In general quality of debug info is one place I have had fewer issues with gcc/gdb than I have with clang/lldb.
loeg 6y ago
Clang loses a lot of information for values that are still available or computable in its optimization passes. It's not purely the values being completely lost to optimization. GCC continues to emit relatively better debuginfo at similar optimization levels. Samy Al Bahra has written and talked about this a couple of times over the years.
- brandmeyer 6y ago
  I dunno, I see the same issue in GCC, even at -Og. Both compilers will aggressively mark variables dead and reuse their (memory, registers) as soon as possible. Just because its in scope, doesn't mean its still live.
  - loeg 6y ago
    Yes, scope and liveness are not exactly the same. No, that does not mean the scoped value cannot be restored cheaply. DWARF can express the value of a variable in terms of expressions that do computations on other registers and/or access memory; it does not have to be as simplistic as "this value lives in this register for some period of time." Clang (and to a lesser extent, GCC) fail to do that for non-live, in-scope registers much of the time. Clang in particular just loses that metadata in many optimization passes.