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

...es is fine. > > (example: DW_AT_sibling) > > o Extensions are okay, but think about the circumstances where they > > would be useful (versus just wasting space). These are probably a > > debugger tuning decision, but might be a target-based decision. > > (example: DW_AT_APPLE_* attributes) > > o If some debugger can't tolerate some piece of standard DWARF, that's > > a missing feature or a bug in the debugger. Accommodating that in > > the compiler is a debugger tuning decision. > > (example: DW_OP_form_tls_address not understood by GD...

We're inconsistent about using DW_AT_MIPS_linkage_name versus DW_AT_linkage_name. Variables (see DwarfCompileUnit::getOrCreateGlobalVariableDIE()) get the standard attribute for DWARF >= 4, MIPS for older. Subprograms (see DwarfUnit::applySubprogramDefinitionAttributes()) always get DW_AT_MIPS_linkage_name (no version check). Before I go drudging through however many tests will die if I

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

...g) > >>>> o Extensions are okay, but think about the circumstances where they > >>>> would be useful (versus just wasting space). These are probably a > >>>> debugger tuning decision, but might be a target-based decision. > >>>> (example: DW_AT_APPLE_* attributes) > >>>> o If some debugger can't tolerate some piece of standard DWARF, that's > >>>> a missing feature or a bug in the debugger. Accommodating that in > >>>> the compiler is a debugger tuning decision. > >>>> (example...

...itting standard DWARF features that nobody uses is fine. (example: DW_AT_sibling) o Extensions are okay, but think about the circumstances where they would be useful (versus just wasting space). These are probably a debugger tuning decision, but might be a target-based decision. (example: DW_AT_APPLE_* attributes) o If some debugger can't tolerate some piece of standard DWARF, that's a missing feature or a bug in the debugger. Accommodating that in the compiler is a debugger tuning decision. (example: DW_OP_form_tls_address not understood by GDB) o If some debugger has no use for...

...xample: DW_AT_sibling) >>>> o Extensions are okay, but think about the circumstances where they >>>> would be useful (versus just wasting space). These are probably a >>>> debugger tuning decision, but might be a target-based decision. >>>> (example: DW_AT_APPLE_* attributes) >>>> o If some debugger can't tolerate some piece of standard DWARF, that's >>>> a missing feature or a bug in the debugger. Accommodating that in >>>> the compiler is a debugger tuning decision. >>>> (example: DW_OP_form_tls_add...

...g) > >>>> o Extensions are okay, but think about the circumstances where they > >>>> would be useful (versus just wasting space). These are probably a > >>>> debugger tuning decision, but might be a target-based decision. > >>>> (example: DW_AT_APPLE_* attributes) > >>>> o If some debugger can't tolerate some piece of standard DWARF, that's > >>>> a missing feature or a bug in the debugger. Accommodating that in > >>>> the compiler is a debugger tuning decision. > >>>> (example...

...xample: DW_AT_sibling) >>>> o Extensions are okay, but think about the circumstances where they >>>> would be useful (versus just wasting space). These are probably a >>>> debugger tuning decision, but might be a target-based decision. >>>> (example: DW_AT_APPLE_* attributes) >>>> o If some debugger can't tolerate some piece of standard DWARF, that's >>>> a missing feature or a bug in the debugger. Accommodating that in >>>> the compiler is a debugger tuning decision. >>>> (example: DW_OP_form_tls_add...

...mitting standard DWARF features that nobody uses is fine. (example: DW_AT_sibling) o Extensions are okay, but think about the circumstances where they would be useful (versus just wasting space). These are probably a debugger tuning decision, but might be a target-based decision. (example: DW_AT_APPLE_* attributes) o If some debugger can't tolerate some piece of standard DWARF, that's a missing feature or a bug in the debugger. Accommodating that in the compiler is a debugger tuning decision. (example: DW_OP_form_tls_address not understood by GDB) o If some debugger has no use for...

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

> -----Original Message----- > From: Daniel Berlin [mailto:dberlin at dberlin.org] > Sent: Friday, May 01, 2015 3:15 PM > To: Robinson, Paul > Cc: cfe-dev at cs.uiuc.edu Developers (cfe-dev at cs.uiuc.edu); LLVM Developers > Mailing List (llvmdev at cs.uiuc.edu); lldb-dev at cs.uiuc.edu > Subject: Re: [LLVMdev] What does "debugger tuning" mean? > > On Fri, May