search for: dw_at_apple

..., 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...

...rfDebug ctor, that probably should be replaced with a proper feature flag that gets defaulted appropriately in the ctor. (Which also lets us remove the IsDarwin field from the class.) Add feature flags for the various other things mentioned on the thread (linkage names, figuring out what to do with DW_AT_APPLE_* attributes, etc) with appropriate defaulting. Oh yeah, the Clang command-line option, which has its own review (http://reviews.llvm.org/D8599) but needs a whole 'nother round of discussion and bikeshedding that didn't seem relevant to the LLVM part. I haven't been pinging it because...

...9;s currently not a tuning thing, and support for it isn't particularly widespread. > If LLVM doesn't do target-specific defaulting, then Clang would have to. Since you are calling out “no accelerator tables”, this made me think about how the .apple-* accelerator tables (and most of the DW_AT_APPLE* attributes) fit into this. I sounds like they should be target-specific on Darwin while also being enabled by the LLDB tuning option: On Darwin, both LLDB and the Apple version of GDB support them, while on Linux they are only supported by LLDB. > Second: The GNU TLS opcode thing is really a G...