shac ron ₪Ten years ago today #Apple launched the #iPhone 5S and announced the #arm64 CPU inside. It was the first public disclosure of a 64-bit ARM architecture, and it was available for you to buy in a phone. Nobody else was even close to having a chip ready to tape out, much less put in a product, and it was a performance monster.
For many of us it was the culmination of years of effort creating this chip and porting all of our software to it. I was working on the kernel and EL3 monitor. When we started we had no compiler, no assembler, no debugger, and really no documentation and the ISA still in flux. Someone wrote a macro-based assembler. Code gen bugs were a huge problem as clang was adding support. LLDB never caught up so someone on my team did a port of GDB.
raytraced@shac @steve gdb on macos rip. i’m sure there’re great technical advantages to lldb, but i always thought that the spotlighton for lldb should have opened with “forget everything you know about debugging.” the gnu quick reference format is still the north star https://www.cs.utexas.edu/~dahlin/Classes/UGOS/reading/gdb-ref.pdf. it’s the gnu equivalent of “all of our products fit on one table”.
@raytraced @steve LLDB was designed to be used by machines, specifically Xcode, not humans. The human interface was terrible at the start. It has improved a little over the years.
Saagar Jha@shac @raytraced @steve For something intended to be used by machines it fails a lot in ways that require humans to recover
systemd-jaded.timer@shac @raytraced @steve last time i found a bug in lldb i cursed the significant lack of logging. i wound up having to stick rr on it and then use pernosco iirc.
lldb is. not my favourite debugger.