Adding lldb-dev. LLDB is used in many places other than Darwin; it's used for Linux, Android, FreeBSD, Hexagon, Kalimba and many others.
The problem with having the compiler build for a specific debugger is you don't necessarily know at compile which debugger someone will use. There's nothing that says you can't build an executable with clang and then debug it with both gdb and lldb. I've done that. Ted -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -----Original Message----- From: llvmdev-boun...@cs.uiuc.edu [mailto:llvmdev-boun...@cs.uiuc.edu] On Behalf Of Robinson, Paul Sent: Wednesday, April 15, 2015 5:32 PM To: cfe-...@cs.uiuc.edu Developers (cfe-...@cs.uiuc.edu); LLVM Developers Mailing List (llvm...@cs.uiuc.edu) Subject: [LLVMdev] About the "debugger target" While I've already posted reviews for the initial patches for this (see http://reviews.llvm.org/D8506 and http://reviews.llvm.org/D8599), the grapevine suggests I should post a lengthier description of my intent for the "debugger target." The idea was prompted by a suggestion from Eric Christopher, and I'm running with it. Various bits of the DWARF we produce are conditional on the target platform, or on command-line options with defaults based on the target platform. Other bits aren't but probably ought to be. Some of these are little things: - various Apple-defined attributes (DW_AT_APPLE_*) - TLS opcode (DW_OP_form_tls_address v. DW_OP_GNU_push_tls_address) Some are bigger things: - accelerator tables - pubnames/pubtypes Really these aren't so much _platform_ specific things as they are _debugger_ specific things. For example: - accelerator tables: default on for Darwin, but really on for LLDB. - pubnames/pubtypes: off for Darwin and PS4, but really on for GDB. We're co-opting platform as a proxy for the debugger. Sometimes they are closely tied, but in other cases maybe not so much. I think it is already the case that LLDB is used in more places than just Darwin? But the things that look like they ought to be LLDB-specific are actually implemented as Darwin-specific. That's sub-optimal for the non-Darwin but LLDB-using platforms. I mean, LLDB will still *work* on those platforms, because 99% of what's going on is still standard DWARF, it just won't be "tuned" for how LLDB wants to operate. In most cases on the LLVM side, control of one of these tuning things is via a bool flag in DwarfDebug, and the DwarfDebug ctor is where the actual decision-making takes place. My initial patch to define a debugger target starts in the direction of setting those flags based on debugger, not platform. More could be done, but as I'm not clear on LLDB's scope I didn't want to go too far right away. For example, it would not make me sad to suppress the DW_AT_APPLE* stuff except when the debugger would actually understand it. It's not clear to me whether these really ought to be LLDB attributes, or Darwin, or what, because currently we emit them unconditionally. :-P And quite frankly, I'm looking ahead to fiddling things for PS4. We have no use for linkage names in DWARF, for example, so I'd like to turn that off and save some space. We do want .debug_aranges so I'd like to turn that on by default. And there's a little bit of fine-tuning on exactly what -flimit-debug-info applies to, that we'd like to do (that part is obviously on the Clang side rather than the LLVM side). I hope this helps explain what's going on with the "debugger target" and what I want to do with it. (And apologies for not posting this sooner.) --paulr _______________________________________________ LLVM Developers mailing list llvm...@cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
