* Re: Deprecate DBX/stabs? @ 2017-07-21 14:15 David Edelsohn 2017-07-21 16:03 ` Jim Wilson 2017-07-25 7:18 ` Richard Biener 0 siblings, 2 replies; 12+ messages in thread From: David Edelsohn @ 2017-07-21 14:15 UTC (permalink / raw) To: Nathan Sidwell Cc: Richard Biener, Jim Wilson, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Mike Stump, Iain Sandoe, Nick Clifton, 10walls >>>>> Nathan Sidwell writes: > Let's at least deprecate it. I attach a patch to do so. With the > patch, you'll get a note about dbx being deprecated whenever you use > stabs debugging on a system that prefers stabs (thus both -g and -gstabs > will warn). On systems where stabs is not preferred, -gstabs will not > give you a warning. The patch survices an x86_64-linux bootstrap. Absolutely not. AIX still uses DBX as the primary debugging format. AIX supports DWARF but the AIX toolchain does not fully interoperate with DWARF generated by GCC. With the extensive use of DBX by AIX and regular patches from me to fix xcoff stabs debugging, omitting me from the cc list implies that you really haven't done your homework. Thanks, David ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 14:15 Deprecate DBX/stabs? David Edelsohn @ 2017-07-21 16:03 ` Jim Wilson 2017-07-21 19:15 ` Mike Stump 2017-07-25 7:18 ` Richard Biener 1 sibling, 1 reply; 12+ messages in thread From: Jim Wilson @ 2017-07-21 16:03 UTC (permalink / raw) To: David Edelsohn Cc: Nathan Sidwell, Richard Biener, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Mike Stump, Iain Sandoe, Nick Clifton, 10walls On Fri, Jul 21, 2017 at 7:15 AM, David Edelsohn <dje.gcc@gmail.com> wrote: > AIX still uses DBX as the primary debugging format. AIX supports > DWARF but the AIX toolchain does not fully interoperate with DWARF > generated by GCC. We could still deprecate DBX_DEBUG while leaving XCOFF_DEBUG alone for now. This would encourage people to migrate to DWARF2. We won't be able to drop dbxout.c until both DBX_DEBUG and XCOFF_DEBUG are dropped which could be a while, but we can perhaps avoid any new users of stabs. I see that avr-*, *-lynx, pre-darwin9 32-bit i686-darwin, *-openbsd, pdp11-*, vax-*, and cygwin/mingw32 with obsolete assemblers still default to DBX_DEBUG. Some of those can be dropped, and the others can migrate to dwarf. There is also the matter of SDB_DEBUG which is still supported, and is no longer used by anyone, as we have already deprecated all of the COFF targets that were using it. SDB support for C++ is even worse than the DBX support. This should be no problem to deprecate and remove. We could perhaps even just drop it without bothering to deprecate it first. Jim ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 16:03 ` Jim Wilson @ 2017-07-21 19:15 ` Mike Stump 0 siblings, 0 replies; 12+ messages in thread From: Mike Stump @ 2017-07-21 19:15 UTC (permalink / raw) To: Jim Wilson Cc: David Edelsohn, Nathan Sidwell, Richard Biener, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Iain Sandoe, Nick Clifton, 10walls On Jul 21, 2017, at 9:03 AM, Jim Wilson <jim.wilson@linaro.org> wrote: > There is also the matter of SDB_DEBUG which is still supported, and is > no longer used by anyone, as we have already deprecated all of the > COFF targets that were using it. SDB support for C++ is even worse > than the DBX support. This should be no problem to deprecate and > remove. We could perhaps even just drop it without bothering to > deprecate it first. I think that's reasonable. I haven't used adb and sdb in years. :-) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 14:15 Deprecate DBX/stabs? David Edelsohn 2017-07-21 16:03 ` Jim Wilson @ 2017-07-25 7:18 ` Richard Biener 1 sibling, 0 replies; 12+ messages in thread From: Richard Biener @ 2017-07-25 7:18 UTC (permalink / raw) To: David Edelsohn Cc: Nathan Sidwell, Jim Wilson, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Mike Stump, Iain Sandoe, Nick Clifton, 10walls On Fri, Jul 21, 2017 at 4:15 PM, David Edelsohn <dje.gcc@gmail.com> wrote: >>>>>> Nathan Sidwell writes: > >> Let's at least deprecate it. I attach a patch to do so. With the >> patch, you'll get a note about dbx being deprecated whenever you use >> stabs debugging on a system that prefers stabs (thus both -g and -gstabs >> will warn). On systems where stabs is not preferred, -gstabs will not >> give you a warning. The patch survices an x86_64-linux bootstrap. > > Absolutely not. > > AIX still uses DBX as the primary debugging format. AIX supports > DWARF but the AIX toolchain does not fully interoperate with DWARF > generated by GCC. > > With the extensive use of DBX by AIX and regular patches from me to > fix xcoff stabs debugging, omitting me from the cc list implies that > you really haven't done your homework. The proposal was to define DBX_DEBUG_OK on such targets so their users do not get the deprecation warning. The idea is to remove support for STABS from targets that have well established DWARF support (like xyz-linux). Of course I would like complete STABS deprecation more but I knew that at least AIX stands in the way here ;) Richard. > Thanks, David ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] Kill TYPE_METHODS 0/9 @ 2017-07-14 16:44 Nathan Sidwell 2017-07-14 16:49 ` [PATCH] Kill TYPE_METHODS debug 1/9 Nathan Sidwell 0 siblings, 1 reply; 12+ messages in thread From: Nathan Sidwell @ 2017-07-14 16:44 UTC (permalink / raw) To: GCC Patches; +Cc: Jason Merrill, Richard Guenther, Jim Wilson, Jan Hubicka This is a series of patches that remove the TYPE_METHODS field used in records & unions. Currently TYPE_METHODS hods a the member functions (be they static or non-static), and TYPE_FIELDS holds everything else (be they FIELD_DECLS or whatever). This distinction is unnecessary, and the patches move everything to TYPE_FIELDS. (I do not mess with name lookup, which is handled differently). I do not repurpose TYPE_METHODS, that's later. While the changes are pretty mechanical, some are rather too large outside of the C++ FE to comfortably apply the obvious rule. 1 method-debug.diff - dbxout & dwarf2out. Review please. 2 method-ipa.diff - lto-devirt. Review please. 3 method-rtl.diff - most odd occurrence. Comment please. 4 method-ada.diff - ada-spec generation. Obvious. 5 method-cp.diff - C++ FE changes, self reviewed 6 method-libcc1.diff - libcp1plugin. Obvious. 7 method-misc.diff - random tree.c. Obvious. 8 method-objc.diff - objc. Obvious 9 method-ectomy.diff - delete the macro. Obvious nathan -- Nathan Sidwell ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Kill TYPE_METHODS debug 1/9 2017-07-14 16:44 [PATCH] Kill TYPE_METHODS 0/9 Nathan Sidwell @ 2017-07-14 16:49 ` Nathan Sidwell 2017-07-18 17:24 ` Jim Wilson 0 siblings, 1 reply; 12+ messages in thread From: Nathan Sidwell @ 2017-07-14 16:49 UTC (permalink / raw) To: GCC Patches; +Cc: Jason Merrill, Richard Guenther, Jim Wilson, Jan Hubicka [-- Attachment #1: Type: text/plain, Size: 695 bytes --] This changes dbxout and dwarf2out. Rather than iterate over the TYPE_METHODS, they now need to deal with member fns in the regular TYPE_FIELDS iteration. dbxout was a little weirdly convoluted, apparently presuming that functions with the same name are all together. That's not true, so other than maybe slight debug bloat in cases when they happen to be adjacent, it seems more sensible to handle each member function as a separate item. The dwarf2out changes are just moving the processing to the TYPE_FIELDS loop, and thereby deleting some duplicate code. I'd appreciate a review of this patch. Oh, the patch series survived a bootstrap on x86_64-linux. nathan -- Nathan Sidwell [-- Attachment #2: method-debug.diff --] [-- Type: text/plain, Size: 6356 bytes --] 2017-07-14 Nathan Sidwell <nathan@acm.org> gcc/ * dbxout.c (dbxout_type_fields): Member fns are on TYPE_FIELDS. (dbxout_type_method_1, dbxout_type_methods): Delete. (dbxout_type_fn_member): New, constructed from previous. (dbxout_type): No TYPE_METHODS scan. * dwarf2out.c (gen_member_die): Member fns are on TYPE_FIELDS. Index: gcc/dbxout.c =================================================================== --- gcc/dbxout.c (revision 250160) +++ gcc/dbxout.c (working copy) @@ -311,8 +311,7 @@ static void dbxout_typedefs (tree); static void dbxout_type_index (tree); static void dbxout_args (tree); static void dbxout_type_fields (tree); -static void dbxout_type_method_1 (tree); -static void dbxout_type_methods (tree); +static void dbxout_type_fn_member (tree); static void dbxout_range_type (tree, tree, tree); static void dbxout_type (tree, int); static bool print_int_cst_bounds_in_octal_p (tree, tree, tree); @@ -1493,6 +1492,8 @@ dbxout_type_fields (tree type) || ! tree_fits_uhwi_p (DECL_SIZE (tem))))) continue; + else if (TREE_CODE (tem) == FUNCTION_DECL) + dbxout_type_fn_member (tem); else if (TREE_CODE (tem) != CONST_DECL) { /* Continue the line if necessary, @@ -1542,14 +1543,23 @@ dbxout_type_fields (tree type) } } \f -/* Subroutine of `dbxout_type_methods'. Output debug info about the - method described DECL. */ +/* Subroutine of `dbxout_type'. Output debug info about the + function member DECL. */ static void -dbxout_type_method_1 (tree decl) +dbxout_type_fn_member (tree decl) { + if (!use_gnu_debug_info_extensions) + return; + char c1 = 'A', c2; + CONTIN; + stabstr_I (DECL_NAME (decl)); + stabstr_S ("::"); + + dbxout_type (TREE_TYPE (decl), 0); + if (TREE_CODE (TREE_TYPE (decl)) == FUNCTION_TYPE) c2 = '?'; else /* it's a METHOD_TYPE. */ @@ -1586,72 +1596,7 @@ dbxout_type_method_1 (tree decl) dbxout_type (DECL_CONTEXT (decl), 0); stabstr_C (';'); } -} -\f -/* Subroutine of `dbxout_type'. Output debug info about the methods defined - in TYPE. */ - -static void -dbxout_type_methods (tree type) -{ - /* C++: put out the method names and their parameter lists */ - tree methods = TYPE_METHODS (type); - tree fndecl; - tree last; - - if (methods == NULL_TREE) - return; - - if (TREE_CODE (methods) != TREE_VEC) - fndecl = methods; - else if (TREE_VEC_ELT (methods, 0) != NULL_TREE) - fndecl = TREE_VEC_ELT (methods, 0); - else - fndecl = TREE_VEC_ELT (methods, 1); - - while (fndecl) - { - int need_prefix = 1; - - /* Group together all the methods for the same operation. - These differ in the types of the arguments. */ - for (last = NULL_TREE; - fndecl && (last == NULL_TREE || DECL_NAME (fndecl) == DECL_NAME (last)); - fndecl = DECL_CHAIN (fndecl)) - /* Output the name of the field (after overloading), as - well as the name of the field before overloading, along - with its parameter list */ - { - /* Skip methods that aren't FUNCTION_DECLs. (In C++, these - include TEMPLATE_DECLs.) The debugger doesn't know what - to do with such entities anyhow. */ - if (TREE_CODE (fndecl) != FUNCTION_DECL) - continue; - - CONTIN; - - last = fndecl; - - /* Also ignore abstract methods; those are only interesting to - the DWARF backends. */ - if (DECL_IGNORED_P (fndecl) || DECL_ABSTRACT_P (fndecl)) - continue; - - /* Redundantly output the plain name, since that's what gdb - expects. */ - if (need_prefix) - { - stabstr_I (DECL_NAME (fndecl)); - stabstr_S ("::"); - need_prefix = 0; - } - - dbxout_type (TREE_TYPE (fndecl), 0); - dbxout_type_method_1 (fndecl); - } - if (!need_prefix) - stabstr_C (';'); - } + stabstr_C (';'); } /* Emit a "range" type specification, which has the form: @@ -2211,10 +2156,6 @@ dbxout_type (tree type, int full) /* Write out the field declarations. */ dbxout_type_fields (type); - if (use_gnu_debug_info_extensions && TYPE_METHODS (type) != NULL_TREE) - { - dbxout_type_methods (type); - } stabstr_C (';'); Index: gcc/dwarf2out.c =================================================================== --- gcc/dwarf2out.c (revision 250160) +++ gcc/dwarf2out.c (working copy) @@ -24088,7 +24088,8 @@ gen_member_die (tree type, dw_die_ref co { tree member; tree binfo = TYPE_BINFO (type); - dw_die_ref child; + + gcc_assert (TYPE_MAIN_VARIANT (type) == type); /* If this is not an incomplete type, output descriptions of each of its members. Note that as we output the DIEs necessary to represent the @@ -24125,13 +24126,16 @@ gen_member_die (tree type, dw_die_ref co && (lang_hooks.decls.decl_dwarf_attribute (member, DW_AT_inline) != -1)); + /* Ignore clones. */ + if (DECL_ABSTRACT_ORIGIN (member)) + continue; + /* If we thought we were generating minimal debug info for TYPE and then changed our minds, some of the member declarations may have already been defined. Don't define them again, but do put them in the right order. */ - child = lookup_decl_die (member); - if (child) + if (dw_die_ref child = lookup_decl_die (member)) { /* Handle inline static data members, which only have in-class declarations. */ @@ -24159,6 +24163,7 @@ gen_member_die (tree type, dw_die_ref co static_inline_p = false; } } + if (child->die_tag == DW_TAG_variable && child->die_parent == comp_unit_die () && ref == NULL) @@ -24197,23 +24202,6 @@ gen_member_die (tree type, dw_die_ref co DECL_EXTERNAL (member) = old_extern; } } - - /* We do not keep type methods in type variants. */ - gcc_assert (TYPE_MAIN_VARIANT (type) == type); - /* Now output info about the function members (if any). */ - if (TYPE_METHODS (type) != error_mark_node) - for (member = TYPE_METHODS (type); member; member = DECL_CHAIN (member)) - { - /* Don't include clones in the member list. */ - if (DECL_ABSTRACT_ORIGIN (member)) - continue; - - child = lookup_decl_die (member); - if (child) - splice_child_die (context_die, child); - else - gen_decl_die (member, NULL, NULL, context_die); - } } /* Generate a DIE for a structure or union type. If TYPE_DECL_SUPPRESS_DEBUG ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Kill TYPE_METHODS debug 1/9 2017-07-14 16:49 ` [PATCH] Kill TYPE_METHODS debug 1/9 Nathan Sidwell @ 2017-07-18 17:24 ` Jim Wilson 2017-07-20 11:31 ` Nathan Sidwell 0 siblings, 1 reply; 12+ messages in thread From: Jim Wilson @ 2017-07-18 17:24 UTC (permalink / raw) To: Nathan Sidwell, GCC Patches Cc: Jason Merrill, Richard Guenther, Jim Wilson, Jan Hubicka On 07/14/2017 09:48 AM, Nathan Sidwell wrote: > This changes dbxout and dwarf2out. > Oh, the patch series survived a bootstrap on x86_64-linux. Changes to the debug info files requires a gdb make check with and without the patch to check for regressions. Since you are changing both dbxout and dwarf2out, you would need to do this twice, once for each debug info type. Testing dbxout may be a little tricky, since few systems still use this by default. Maybe you can hack an x86_64-linux build to use dbxout by default to test it. Otherwise, this looks OK. Jim ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Kill TYPE_METHODS debug 1/9 2017-07-18 17:24 ` Jim Wilson @ 2017-07-20 11:31 ` Nathan Sidwell 2017-07-20 12:13 ` Nathan Sidwell 0 siblings, 1 reply; 12+ messages in thread From: Nathan Sidwell @ 2017-07-20 11:31 UTC (permalink / raw) To: Jim Wilson, GCC Patches Cc: Jason Merrill, Richard Guenther, Jim Wilson, Jan Hubicka On 07/18/2017 01:24 PM, Jim Wilson wrote: > Changes to the debug info files requires a gdb make check with and > without the patch to check for regressions. Since you are changing both > dbxout and dwarf2out, you would need to do this twice, once for each > debug info type. Testing dbxout may be a little tricky, since few > systems still use this by default. Maybe you can hack an x86_64-linux > build to use dbxout by default to test it. DWARF results are unchanged. DBX results after hacking x86-64 to prefer stabs are too horrible to tell. However, a manual check on a simple program shows that gdb couldn't locate member functions anyway even before the patch and an unhacked g++. g++ -gstabs: (gdb) ptype X type = struct X { int m; } g++ -gdwarf: (gdb) ptype X type = struct X { int m; public: int frob(int); X(int); } So I don't think I've made it worse there. thoughts? nathan -- Nathan Sidwell ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Kill TYPE_METHODS debug 1/9 2017-07-20 11:31 ` Nathan Sidwell @ 2017-07-20 12:13 ` Nathan Sidwell 2017-07-20 21:00 ` Nathan Sidwell 0 siblings, 1 reply; 12+ messages in thread From: Nathan Sidwell @ 2017-07-20 12:13 UTC (permalink / raw) To: Jim Wilson, GCC Patches Cc: Jason Merrill, Richard Guenther, Jim Wilson, Jan Hubicka On 07/20/2017 07:31 AM, Nathan Sidwell wrote: > So I don't think I've made it worse there. thoughts? aha, gstabs+ for gnu extensions. With a small fix I get the following before and after (I changed the example to add another frob member). (gdb) ptype X type = struct X { public: int frob(int); int frob(float); X(int); X(int); } The fragment I'd missed is losing: /* Also ignore abstract methods; those are only interesting to the DWARF backends. */ if (DECL_IGNORED_P (decl) || DECL_ABSTRACT_P (decl)) return; which inhibits the abstract ctor. nathan -- Nathan Sidwell ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Kill TYPE_METHODS debug 1/9 2017-07-20 12:13 ` Nathan Sidwell @ 2017-07-20 21:00 ` Nathan Sidwell 2017-07-20 22:04 ` Jim Wilson 0 siblings, 1 reply; 12+ messages in thread From: Nathan Sidwell @ 2017-07-20 21:00 UTC (permalink / raw) To: Jim Wilson, GCC Patches Cc: Jason Merrill, Richard Guenther, Jim Wilson, Jan Hubicka [-- Attachment #1: Type: text/plain, Size: 749 bytes --] A bit more poking showed that dbx's desire to put all methods of the same name in a single record was significant -- gdb requires that to build an overload set. So, this version of the dbxout changes is much smaller, in that we iterate the TYPE_FIELDS twice. There's the original scan, which just needs to now skip FUNCTION_DECLs as well. The method emission routine now iterates over TYPE_FIELDS again, skipping everything that is not a FUNCTION_DECL. I preserve the previous behaviour of merging decls with the same name -- of course it'll still fail in the same manner if you declare overloads discontigously. With this patch the gdb stabs test results are still awful, but they are unchanged awfulness. nathan -- Nathan Sidwell [-- Attachment #2: 1a-method-dbx.diff --] [-- Type: text/x-patch, Size: 3042 bytes --] 2017-07-20 Nathan Sidwell <nathan@acm.org> * dbxout.c (dbxout_type_fields): Ignore FUNCTION_DECLs. (dbxout_type_methods): Scan TYPE_FIELDS. (dbxout_type): Don't check TYPE_METHODS here. Index: dbxout.c =================================================================== --- dbxout.c (revision 250318) +++ dbxout.c (working copy) @@ -1481,6 +1481,8 @@ dbxout_type_fields (tree type) /* Omit here local type decls until we know how to support them. */ if (TREE_CODE (tem) == TYPE_DECL || TREE_CODE (tem) == TEMPLATE_DECL + /* Member functions emitted after fields. */ + || TREE_CODE (tem) == FUNCTION_DECL /* Omit here the nameless fields that are used to skip bits. */ || DECL_IGNORED_P (tem) /* Omit fields whose position or size are variable or too large to @@ -1586,55 +1588,38 @@ dbxout_type_method_1 (tree decl) } } \f -/* Subroutine of `dbxout_type'. Output debug info about the methods defined - in TYPE. */ +/* Subroutine of `dbxout_type'. Output debug info about the member + functions defined in TYPE. */ static void dbxout_type_methods (tree type) { - /* C++: put out the method names and their parameter lists */ - tree methods = TYPE_METHODS (type); - tree fndecl; - tree last; - - if (methods == NULL_TREE) - return; - - if (TREE_CODE (methods) != TREE_VEC) - fndecl = methods; - else if (TREE_VEC_ELT (methods, 0) != NULL_TREE) - fndecl = TREE_VEC_ELT (methods, 0); - else - fndecl = TREE_VEC_ELT (methods, 1); - - while (fndecl) + for (tree fndecl = TYPE_FIELDS (type); fndecl;) { int need_prefix = 1; /* Group together all the methods for the same operation. These differ in the types of the arguments. */ - for (last = NULL_TREE; + for (tree last = NULL_TREE; fndecl && (last == NULL_TREE || DECL_NAME (fndecl) == DECL_NAME (last)); fndecl = DECL_CHAIN (fndecl)) /* Output the name of the field (after overloading), as well as the name of the field before overloading, along with its parameter list */ { - /* Skip methods that aren't FUNCTION_DECLs. (In C++, these - include TEMPLATE_DECLs.) The debugger doesn't know what - to do with such entities anyhow. */ + /* Skip non-functions. */ if (TREE_CODE (fndecl) != FUNCTION_DECL) continue; - CONTIN; - - last = fndecl; - /* Also ignore abstract methods; those are only interesting to the DWARF backends. */ if (DECL_IGNORED_P (fndecl) || DECL_ABSTRACT_P (fndecl)) continue; + CONTIN; + + last = fndecl; + /* Redundantly output the plain name, since that's what gdb expects. */ if (need_prefix) @@ -2209,10 +2194,8 @@ dbxout_type (tree type, int full) /* Write out the field declarations. */ dbxout_type_fields (type); - if (use_gnu_debug_info_extensions && TYPE_METHODS (type) != NULL_TREE) - { - dbxout_type_methods (type); - } + if (use_gnu_debug_info_extensions) + dbxout_type_methods (type); stabstr_C (';'); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Kill TYPE_METHODS debug 1/9 2017-07-20 21:00 ` Nathan Sidwell @ 2017-07-20 22:04 ` Jim Wilson 2017-07-21 5:11 ` Richard Biener 0 siblings, 1 reply; 12+ messages in thread From: Jim Wilson @ 2017-07-20 22:04 UTC (permalink / raw) To: Nathan Sidwell Cc: GCC Patches, Jason Merrill, Richard Guenther, Jim Wilson, Jan Hubicka On Thu, Jul 20, 2017 at 2:00 PM, Nathan Sidwell <nathan@acm.org> wrote: > With this patch the gdb stabs test results are still awful, but they are > unchanged awfulness. Yes, the stabs support for C++ is poor. That is one of the reasons why almost everyone has switched to dwarf2. I wasn't sure what to make of your last message, so I tried to see if I could build a toolchain that defaults to stabs so I could look at this. I discovered that -freorder-functions doesn't work with stabs on an elf target, as we get a cross section label subtraction that the assembler can't compute. I had to manually disable that optimization. I also had to disable the x86 specific change to enable -freorder-blocks-and-partition at -O2. I managed to get it working for x86_64-linux and i686-pc-cygwin. But the fact that -O2 and stabs don't work together by default anymore suggest that there are no serious stabs users except on old legacy systems that don't support named sections, and hence don't support -freorder-functions. I also noticed that there is a config/i386/gstabs.h file that has been unused since the openbsd 2 and 3 support was removed last year, and should be deleted. Anyways, your new dbxout.c patch looks good. And maybe we should think about deprecating the stabs support some day. Jim ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Kill TYPE_METHODS debug 1/9 2017-07-20 22:04 ` Jim Wilson @ 2017-07-21 5:11 ` Richard Biener 2017-07-21 13:08 ` Deprecate DBX/stabs? Nathan Sidwell 0 siblings, 1 reply; 12+ messages in thread From: Richard Biener @ 2017-07-21 5:11 UTC (permalink / raw) To: Jim Wilson, Nathan Sidwell Cc: GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka On July 21, 2017 12:03:58 AM GMT+02:00, Jim Wilson <jim.wilson@linaro.org> wrote: >On Thu, Jul 20, 2017 at 2:00 PM, Nathan Sidwell <nathan@acm.org> wrote: >> With this patch the gdb stabs test results are still awful, but they >are >> unchanged awfulness. > >Yes, the stabs support for C++ is poor. That is one of the reasons >why almost everyone has switched to dwarf2. > >I wasn't sure what to make of your last message, so I tried to see if >I could build a toolchain that defaults to stabs so I could look at >this. I discovered that -freorder-functions doesn't work with stabs >on an elf target, as we get a cross section label subtraction that the >assembler can't compute. I had to manually disable that optimization. >I also had to disable the x86 specific change to enable >-freorder-blocks-and-partition at -O2. I managed to get it working >for x86_64-linux and i686-pc-cygwin. But the fact that -O2 and stabs >don't work together by default anymore suggest that there are no >serious stabs users except on old legacy systems that don't support >named sections, and hence don't support -freorder-functions. > >I also noticed that there is a config/i386/gstabs.h file that has been >unused since the openbsd 2 and 3 support was removed last year, and >should be deleted. > >Anyways, your new dbxout.c patch looks good. And maybe we should >think about deprecating the stabs support some day. I've suggested that multiple times also to be able to get rid of the debug hook interfacing in GCC and emit dwarf directly from FEs where that makes sense. DWARF should be a superset of other debug formats so it should be possible to build stabs from dwarf. Richard. >Jim ^ permalink raw reply [flat|nested] 12+ messages in thread
* Deprecate DBX/stabs? 2017-07-21 5:11 ` Richard Biener @ 2017-07-21 13:08 ` Nathan Sidwell 2017-07-21 13:16 ` Richard Biener ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Nathan Sidwell @ 2017-07-21 13:08 UTC (permalink / raw) To: Richard Biener, Jim Wilson Cc: GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, mikestump, iain, Nick Clifton, 10walls [-- Attachment #1: Type: text/plain, Size: 1679 bytes --] [darwin, cygwin, rx maintainers, you might have an opinion] On 07/21/2017 01:11 AM, Richard Biener wrote: > On July 21, 2017 12:03:58 AM GMT+02:00, Jim Wilson <jim.wilson@linaro.org> wrote: >> On Thu, Jul 20, 2017 at 2:00 PM, Nathan Sidwell <nathan@acm.org> wrote: >>> With this patch the gdb stabs test results are still awful, but they >> are >>> unchanged awfulness. >> >> Anyways, your new dbxout.c patch looks good. And maybe we should >> think about deprecating the stabs support some day. > > I've suggested that multiple times also to be able to get rid of the debug hook interfacing in GCC and emit dwarf directly from FEs where that makes sense. DWARF should be a superset of other debug formats so it should be possible to build stabs from dwarf. Let's at least deprecate it. I attach a patch to do so. With the patch, you'll get a note about dbx being deprecated whenever you use stabs debugging on a system that prefers stabs (thus both -g and -gstabs will warn). On systems where stabs is not preferred, -gstabs will not give you a warning. The patch survices an x86_64-linux bootstrap. A config can chose to override thus by defining 'DBX_DEBUG_OK' in the build defines. I did try build time CPP tricks, but config/rx.h and config/i386/darwin.h define it to be a conditional expression. AFAICT, the following include files are not used, and could probably be binned too: config/dbx.h config/dbxcoff.h config/dbxelf.h (+ configi386/gstabs.h Jim found) It looks like DBX is the default for: i386/cygming configured for 32-bit or lacking PE_SECREL32_RELOC i386/darwin.h for 32-bit target rx/rx.h when using AS100 syntax nathan -- Nathan Sidwell [-- Attachment #2: dbx-dep.diff --] [-- Type: text/x-patch, Size: 672 bytes --] 2017-07-21 Nathan Sidwell <nathan@acm.org> * toplev.c (process_options): Warn about DBX being deprecated. Index: toplev.c =================================================================== --- toplev.c (revision 250424) +++ toplev.c (working copy) @@ -1413,6 +1413,12 @@ process_options (void) debug_info_level = DINFO_LEVEL_NONE; } +#ifndef DBX_DEBBUG_OK + if (PREFERRED_DEBUGGING_TYPE == DBX_DEBUG + && write_symbols == DBX_DEBUG) + inform (UNKNOWN_LOCATION, "DBX (stabs) debugging is deprecated"); +#endif + if (flag_dump_final_insns && !flag_syntax_only && !no_backend) { FILE *final_output = fopen (flag_dump_final_insns, "w"); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 13:08 ` Deprecate DBX/stabs? Nathan Sidwell @ 2017-07-21 13:16 ` Richard Biener 2017-07-21 14:06 ` Nathan Sidwell 2017-07-21 19:10 ` Mike Stump 2017-07-22 1:22 ` JonY 2 siblings, 1 reply; 12+ messages in thread From: Richard Biener @ 2017-07-21 13:16 UTC (permalink / raw) To: Nathan Sidwell Cc: Jim Wilson, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Mike Stump, iain, Nick Clifton, 10walls On Fri, Jul 21, 2017 at 3:07 PM, Nathan Sidwell <nathan@acm.org> wrote: > [darwin, cygwin, rx maintainers, you might have an opinion] > > On 07/21/2017 01:11 AM, Richard Biener wrote: >> >> On July 21, 2017 12:03:58 AM GMT+02:00, Jim Wilson <jim.wilson@linaro.org> >> wrote: >>> >>> On Thu, Jul 20, 2017 at 2:00 PM, Nathan Sidwell <nathan@acm.org> wrote: >>>> >>>> With this patch the gdb stabs test results are still awful, but they >>> >>> are >>>> >>>> unchanged awfulness. >>> >>> >>> Anyways, your new dbxout.c patch looks good. And maybe we should >>> think about deprecating the stabs support some day. >> >> >> I've suggested that multiple times also to be able to get rid of the debug >> hook interfacing in GCC and emit dwarf directly from FEs where that makes >> sense. DWARF should be a superset of other debug formats so it should be >> possible to build stabs from dwarf. > > > Let's at least deprecate it. I attach a patch to do so. With the patch, > you'll get a note about dbx being deprecated whenever you use stabs > debugging on a system that prefers stabs (thus both -g and -gstabs will > warn). On systems where stabs is not preferred, -gstabs will not give you a > warning. The patch survices an x86_64-linux bootstrap. > > A config can chose to override thus by defining 'DBX_DEBUG_OK' in the build > defines. > > I did try build time CPP tricks, but config/rx.h and config/i386/darwin.h > define it to be a conditional expression. > > AFAICT, the following include files are not used, and could probably be > binned too: > config/dbx.h > config/dbxcoff.h > config/dbxelf.h > (+ configi386/gstabs.h Jim found) > > It looks like DBX is the default for: > i386/cygming configured for 32-bit or lacking PE_SECREL32_RELOC > i386/darwin.h for 32-bit target > rx/rx.h when using AS100 syntax Index: toplev.c =================================================================== --- toplev.c (revision 250424) +++ toplev.c (working copy) @@ -1413,6 +1413,12 @@ process_options (void) debug_info_level = DINFO_LEVEL_NONE; } +#ifndef DBX_DEBBUG_OK ^^^ typo? The patch doesn't define this anywhere - I suggest to add it to defaults.h as 0 and use #if? Also would need documenting if this is supposed to be a target macro. Thanks, Richard. > nathan > -- > Nathan Sidwell ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 13:16 ` Richard Biener @ 2017-07-21 14:06 ` Nathan Sidwell 0 siblings, 0 replies; 12+ messages in thread From: Nathan Sidwell @ 2017-07-21 14:06 UTC (permalink / raw) To: Richard Biener Cc: Jim Wilson, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Mike Stump, iain, Nick Clifton, 10walls [-- Attachment #1: Type: text/plain, Size: 482 bytes --] On 07/21/2017 09:16 AM, Richard Biener wrote: > On Fri, Jul 21, 2017 at 3:07 PM, Nathan Sidwell <nathan@acm.org> wrote: > +#ifndef DBX_DEBBUG_OK > ^^^ > typo? The patch doesn't define this anywhere - I suggest to add it to > defaults.h > as 0 and use #if? Also would need documenting if this is supposed to be a > target macro. Like this? I've now included XCOFF, as it's a subset of DBX. Nothing appears to default to it. nathan -- Nathan Sidwell [-- Attachment #2: dbx-dep.diff --] [-- Type: text/x-patch, Size: 2976 bytes --] 2017-07-21 Nathan Sidwell <nathan@acm.org> * defaults.h (DBX_DEBUG_DEPRECATED): New. * toplev.c (process_options): Warn about DBX/SDB being deprecated. * doc/tm.texi.in (DBX_DEBUG_DEPRECATED): Document. * doc/tm.texi: Updated. Index: defaults.h =================================================================== --- defaults.h (revision 250426) +++ defaults.h (working copy) @@ -889,6 +889,12 @@ see the files COPYING3 and COPYING.RUNTI #define SDB_DEBUGGING_INFO 0 #endif +/* DBX debugging is deprecated, and will generate a note if you + default to it. */ +#ifndef DBX_DEBUG_DEPRECATED +#define DBX_DEBUG_DEPRECATED 1 +#endif + /* If more than one debugging type is supported, you must define PREFERRED_DEBUGGING_TYPE to choose the default. */ Index: doc/tm.texi =================================================================== --- doc/tm.texi (revision 250426) +++ doc/tm.texi (working copy) @@ -9553,6 +9553,14 @@ user can always get a specific type of o @c prevent bad page break with this line These are specific options for DBX output. +DBX debug data is deprecated and is expected to be removed. + +@defmac DBX_DEBUG_DEPRECATED +Defined this macro to 1 if GCC should not warn about defaulting to DBX +or XCOFF debug output. This is intended to give maintainers notice of +deprecation, but not be unnecessarily invasive. Defining this macro is +a short-term measure. You need to plan for DBX's removal. +@end defmac @defmac DBX_DEBUGGING_INFO Define this macro if GCC should produce debugging output for DBX Index: doc/tm.texi.in =================================================================== --- doc/tm.texi.in (revision 250426) +++ doc/tm.texi.in (working copy) @@ -6842,6 +6842,14 @@ user can always get a specific type of o @c prevent bad page break with this line These are specific options for DBX output. +DBX debug data is deprecated and is expected to be removed. + +@defmac DBX_DEBUG_DEPRECATED +Defined this macro to 1 if GCC should not warn about defaulting to DBX +or XCOFF debug output. This is intended to give maintainers notice of +deprecation, but not be unnecessarily invasive. Defining this macro is +a short-term measure. You need to plan for DBX's removal. +@end defmac @defmac DBX_DEBUGGING_INFO Define this macro if GCC should produce debugging output for DBX Index: toplev.c =================================================================== --- toplev.c (revision 250426) +++ toplev.c (working copy) @@ -1413,6 +1413,12 @@ process_options (void) debug_info_level = DINFO_LEVEL_NONE; } + if (DBX_DEBUG_DEPRECATED + && write_symbols == PREFERRED_DEBUGGING_TYPE + && (PREFERRED_DEBUGGING_TYPE == DBX_DEBUG + || PREFERRED_DEBUGGING_TYPE == XCOFF_DEBUG)) + inform (UNKNOWN_LOCATION, "DBX/XCOFF (stabs) debugging is deprecated"); + if (flag_dump_final_insns && !flag_syntax_only && !no_backend) { FILE *final_output = fopen (flag_dump_final_insns, "w"); ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 13:08 ` Deprecate DBX/stabs? Nathan Sidwell 2017-07-21 13:16 ` Richard Biener @ 2017-07-21 19:10 ` Mike Stump 2017-07-21 19:44 ` Iain Sandoe 2017-07-22 1:22 ` JonY 2 siblings, 1 reply; 12+ messages in thread From: Mike Stump @ 2017-07-21 19:10 UTC (permalink / raw) To: Nathan Sidwell Cc: Richard Biener, Jim Wilson, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Iain Sandoe, Nick Clifton, 10walls On Jul 21, 2017, at 6:07 AM, Nathan Sidwell <nathan@acm.org> wrote: > > [darwin, cygwin, rx maintainers, you might have an opinion] darwin going forward is a DWARF platform, so, shouldn't be a heartache for real folks. For ancient machines, ancient compilers might be a requirement. Generally, I like keeping things; but cleanups and removals are a part of life, and eventually the old should be removed. I'd not stand in the way of such removal. If we were within 5 years of such a transition point, I'd argue to keep it for at least 5 years. But, the switch for darwin was Oct 26th, 2007. 10 years I think is a nice cutover point for first tier things. Beyond 10, and I'd say, you are dragging your feet. If _all_ the code for DBX were in my port file, I'd be tempted to keep it indefinitely. It's not, so, that's not possible/reasonable. Iain, do you still have the G5s? :-) Do they run 8 or 9? What do you think? Seem reasonable? The 64_BIT x86 darwin question likely can be be flipped to default to dwarf; so, even that isn't an issue. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 19:10 ` Mike Stump @ 2017-07-21 19:44 ` Iain Sandoe 2017-07-21 19:54 ` Jim Wilson 0 siblings, 1 reply; 12+ messages in thread From: Iain Sandoe @ 2017-07-21 19:44 UTC (permalink / raw) To: Mike Stump Cc: Nathan Sidwell, Richard Biener, Jim Wilson, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Nick Clifton, 10walls > On 21 Jul 2017, at 20:10, Mike Stump <mikestump@comcast.net> wrote: > > On Jul 21, 2017, at 6:07 AM, Nathan Sidwell <nathan@acm.org> wrote: >> >> [Darwin, cygwin, rx maintainers, you might have an opinion] > > darwin going forward is a DWARF platform, so, shouldn't be a heartache for real folks. agreed, in fact the default for current assemblers doesn’t support stabs - and we’ve adjusted the specs to deal with that. > For ancient machines, ancient compilers might be a requirement. Generally, I like keeping things; but cleanups and removals are a part of life, and eventually the old should be removed. I'd not stand in the way of such removal. If we were within 5 years of such a transition point, I'd argue to keep it for at least 5 years. But, the switch for darwin was Oct 26th, 2007. 10 years I think is a nice cutover point for first tier things. Beyond 10, and I'd say, you are dragging your feet. If _all_ the code for DBX were in my port file, I'd be tempted to keep it indefinitely. It's not, so, that's not possible/reasonable. > > Iain, do you still have the G5s? :-) Do they run 8 or 9? What do you think? Seem reasonable? I still have access to i686 and powerpc Darwin8, but testing is extremely infrequent. For the record; anyone wanting modern toolchains on Darwin8 most likely has to face building a linker and more modern cctools anyway(the XCode 2.5 set was extremely flaky from at least 4.6/4.7). I’d suspect that a person serious in doing that would likely be willing to build GDB which does support x86 Darwin, at least. FWIW I have a patch that makes GDB (at least 7.x) work for PowerPC too. If anyone cares, ask ;-) (I doubt if I’ll try modernising it across the transition to c++ for GDB - since available time would prob be better spent elsewhere). Anyone wanting to build modern GCC on < Darwin8 is going to need to build most of the supporting infra too - the (XCode 1.5) linker/assembler there don’t support enough weak stuff to be viable for modern c++. These very old platforms are long past the “config && make” stage, supporting them needs a degree of commitment and understanding. ----- My G5 ( and most of my other ppc hardware) habitually runs 10.5 (Darwin9) and I’ve no motivation to reboot to 10.4 unless to test something more quickly than my really ancient G4s can manage. > The 64_BIT x86 darwin question likely can be be flipped to default to dwarf; so, even that isn't an issue. It ought to be already, in fact anything (powerpc*/x86/x86-64) >= Darwin9 (OS X 10.5) ought to be defaulting to DWARF already, will check that sometime. cheers, Iain Iain Sandoe CodeSourcery / Mentor Embedded ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 19:44 ` Iain Sandoe @ 2017-07-21 19:54 ` Jim Wilson 2017-07-21 20:12 ` Iain Sandoe 0 siblings, 1 reply; 12+ messages in thread From: Jim Wilson @ 2017-07-21 19:54 UTC (permalink / raw) To: Iain Sandoe Cc: Mike Stump, Nathan Sidwell, Richard Biener, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Nick Clifton, 10walls On Fri, Jul 21, 2017 at 12:44 PM, Iain Sandoe <iain@codesourcery.com> wrote: > It ought to be already, in fact anything (powerpc*/x86/x86-64) >= Darwin9 (OS X 10.5) ought to be defaulting to DWARF already, will check that sometime. Yes, they do default to dwarf2. The comments say pre-darwin9 32-bit defaults to stabs. The question is whether anyone cares about that anymore. Jim ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 19:54 ` Jim Wilson @ 2017-07-21 20:12 ` Iain Sandoe 0 siblings, 0 replies; 12+ messages in thread From: Iain Sandoe @ 2017-07-21 20:12 UTC (permalink / raw) To: Jim Wilson Cc: Mike Stump, Nathan Sidwell, Richard Biener, GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, Nick Clifton, 10walls > On 21 Jul 2017, at 20:54, Jim Wilson <jim.wilson@linaro.org> wrote: > > On Fri, Jul 21, 2017 at 12:44 PM, Iain Sandoe <iain@codesourcery.com> wrote: >> It ought to be already, in fact anything (powerpc*/x86/x86-64) >= Darwin9 (OS X 10.5) ought to be defaulting to DWARF already, will check that sometime. > > Yes, they do default to dwarf2. The comments say pre-darwin9 32-bit > defaults to stabs. The question is whether anyone cares about that > anymore. From my perspective, as per Mike’s comments, I’d say “let’s move on”, - Darwin8’s DWARF support is good enough for C at least - as per my other comments, there remain ways forward for someone who really wants to support it (TenFourFox seems still active and I do get a few queries per year from folks working with Darwin8). - deprecation gives other folks a chance to shout if they care. cheers Iain Iain Sandoe CodeSourcery / Mentor Embedded ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Deprecate DBX/stabs? 2017-07-21 13:08 ` Deprecate DBX/stabs? Nathan Sidwell 2017-07-21 13:16 ` Richard Biener 2017-07-21 19:10 ` Mike Stump @ 2017-07-22 1:22 ` JonY 2 siblings, 0 replies; 12+ messages in thread From: JonY @ 2017-07-22 1:22 UTC (permalink / raw) To: Nathan Sidwell, Richard Biener, Jim Wilson Cc: GCC Patches, Jason Merrill, Jim Wilson, Jan Hubicka, mikestump, iain, Nick Clifton [-- Attachment #1.1: Type: text/plain, Size: 1168 bytes --] On 07/21/2017 01:07 PM, Nathan Sidwell wrote: > [darwin, cygwin, rx maintainers, you might have an opinion] > Let's at least deprecate it. I attach a patch to do so. With the > patch, you'll get a note about dbx being deprecated whenever you use > stabs debugging on a system that prefers stabs (thus both -g and -gstabs > will warn). On systems where stabs is not preferred, -gstabs will not > give you a warning. The patch survices an x86_64-linux bootstrap. > > A config can chose to override thus by defining 'DBX_DEBUG_OK' in the > build defines. > > I did try build time CPP tricks, but config/rx.h and > config/i386/darwin.h define it to be a conditional expression. > > AFAICT, the following include files are not used, and could probably be > binned too: > config/dbx.h > config/dbxcoff.h > config/dbxelf.h > (+ configi386/gstabs.h Jim found) > > It looks like DBX is the default for: > i386/cygming configured for 32-bit or lacking PE_SECREL32_RELOC > i386/darwin.h for 32-bit target > rx/rx.h when using AS100 syntax > > nathan Cygwin GCC has been using --with-dwarf2 for sometime now, so it shouldn't be affected. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 858 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-07-25 7:18 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-07-21 14:15 Deprecate DBX/stabs? David Edelsohn 2017-07-21 16:03 ` Jim Wilson 2017-07-21 19:15 ` Mike Stump 2017-07-25 7:18 ` Richard Biener -- strict thread matches above, loose matches on Subject: below -- 2017-07-14 16:44 [PATCH] Kill TYPE_METHODS 0/9 Nathan Sidwell 2017-07-14 16:49 ` [PATCH] Kill TYPE_METHODS debug 1/9 Nathan Sidwell 2017-07-18 17:24 ` Jim Wilson 2017-07-20 11:31 ` Nathan Sidwell 2017-07-20 12:13 ` Nathan Sidwell 2017-07-20 21:00 ` Nathan Sidwell 2017-07-20 22:04 ` Jim Wilson 2017-07-21 5:11 ` Richard Biener 2017-07-21 13:08 ` Deprecate DBX/stabs? Nathan Sidwell 2017-07-21 13:16 ` Richard Biener 2017-07-21 14:06 ` Nathan Sidwell 2017-07-21 19:10 ` Mike Stump 2017-07-21 19:44 ` Iain Sandoe 2017-07-21 19:54 ` Jim Wilson 2017-07-21 20:12 ` Iain Sandoe 2017-07-22 1:22 ` JonY
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).