This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: default to strict dwarf-2 on powerpc-vxworks

On Fri, Apr 13, 2012 at 02:24:09PM +0200, Olivier Hainque wrote:
> On typical VxWorks environments, WindRiver integrated tools are used as
> much if not more than gdb for debugging purposes.
> These evolve at an industrial pace, traditionally not as fast as GCC
> regarding the support of latest dwarf standards.
> As of today, in our experience, the best compromise to let WRS debugging
> tools work fine and have negligible effect on gdb's experience for this
> target is to enforce strict dwarf-2 debugging info by default. 
> We have been doing this in our production compilers for a while and find
> it really useful, so we're happy to contribute here, in case this is deemed
> more generally appropriate. 
> The attached patch achieves this in two mini steps:
> - Allow to distinguish between a dwarf version picked by default by the
>   compiler and one provided on the command line that happens to match the
>   default, which is useful to make sure we don't override a request for
>   an explicit level on the command line.
>   This is achieved by initializing dwarf_version to -1 instead of 2 from
>   common.opt, then pick 2 as a default from toplev.c:process_options,
>   similar to the scheme in place for dwarf_strict already.
> - Default to dwarf_strict = 1 && dwarf_version = 2 for VxWorks via
>   vxworks_override_options.
> Sanity checked on mainline for powerpc-wrs-vxworks and bootstrapped
> on x86_64-pc-linux-gnu.

Looks good to me, but IMHO we should go further at this point, and
default to dwarf_version 4 unless overridden (and override
also on Darwin to too due to its tools not capable of handling it),
probably together with making -fno-debug-types-section the default
(since while DWARF 4 DW_FORM_* etc. support is in gdb/libdw/valgrind/etc.
for quite some time, e.g. .debug_types support is very recent, and
furthermore on lots of programs/DSOs .debug_types actually increases
size instead of decreases.  If a post-linking utility is used
undoing the extra duplication caused by .debug_types (yeah, I know
Cary said he'll work on it) is going to be very hard.  I've noticed
also lots of intra-CU redundancies with current state of .debug_types,
e.g. lots of DW_TAG_{const,pointer,reference}_type DIEs with the same
DW_FORM_ref_sig8 hash).

Jason, are you ok with Olivier's patch?

If yes, I'll post a follow-up to that.

> 2012-04-13  Olivier Hainque  <>
> 	* common.opt (gdwarf-): Initialize dwarf_version to -1 instead of 2.
> 	* toplev.c (process_options): Default to dwarf_version 2.
> 	* config/vxworks.c (vxworks_override_options): Default to strict-dwarf
> 	and dwarf_version 2.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]