* stabs and macro information @ 2003-04-16 15:58 David Taylor 2003-04-16 16:47 ` Daniel Berlin ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: David Taylor @ 2003-04-16 15:58 UTC (permalink / raw) To: gcc, gdb Currently, when invoked with -gdwarf-2 -g3, gcc will record macro information in a .debug_macinfo elf section. And when presented with an executable containing macro information in a .debug_macinfo section, gdb will make use of it. Many companies, including EMC, still use stabs. So... it would be nice if the same was true of stabs. To that end, I have started to implement this. The GCC side of things took less than a day to implement; I'm hoping to get started on the GDB side soon. One question I have is what stabs types to use -- tentatively I'm using: /* GNU extension. Macro define. */ __define_stab(N_MAC_DEFINE, 0x36, "MAC_DEFINE") /* GNU extension. Macro undefine. */ __define_stab(N_MAC_UNDEF, 0x3a, "MAC_UNDEF") as it appears (based on gcc/stab.def, include/aout/stab.def, and gdb/doc/stabs.texinfo) that 0x36 and 0x3a are available. Is anyone aware of any other uses of stab types 0x36 and 0x3a -- i.e. is anyone aware of uses that might conflict? Thanks. David p.s. shouldn't include/aout/stab.def and gcc/stab.def be merged? -- David Taylor dtaylor@emc.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-16 15:58 stabs and macro information David Taylor @ 2003-04-16 16:47 ` Daniel Berlin 2003-04-16 17:16 ` David Taylor 2003-04-16 17:27 ` Daniel Jacobowitz 2003-04-24 3:20 ` Jim Blandy 2 siblings, 1 reply; 11+ messages in thread From: Daniel Berlin @ 2003-04-16 16:47 UTC (permalink / raw) To: David Taylor; +Cc: gcc, gdb On Wednesday, April 16, 2003, at 11:58 AM, David Taylor wrote: > Currently, when invoked with -gdwarf-2 -g3, gcc will record macro > information in a .debug_macinfo elf section. And when presented with > an executable containing macro information in a .debug_macinfo > section, gdb will make use of it. > > Many companies, including EMC, still use stabs. So... it would be > nice if the same was true of stabs. > > To that end, I have started to implement this. > > The GCC side of things took less than a day to implement; I'm hoping > to get started on the GDB side soon. > I didn't see it on the GCC list. Was it submitted? I ask because ... > One question I have is what stabs types to use -- tentatively I'm > using: > > /* GNU extension. Macro define. */ > __define_stab(N_MAC_DEFINE, 0x36, "MAC_DEFINE") > /* GNU extension. Macro undefine. */ > __define_stab(N_MAC_UNDEF, 0x3a, "MAC_UNDEF") > Unless these are really generated by GCC, they aren't GNU extensions, they are EMC extensions. > as it appears (based on gcc/stab.def, include/aout/stab.def, and > gdb/doc/stabs.texinfo) that 0x36 and 0x3a are available. > > Is anyone aware of any other uses of stab types 0x36 and 0x3a -- > i.e. is anyone aware of uses that might conflict? > You might want to look at what Sun's tools do. Do they generate STABS anymore, and if so, see if they have extensions that conflict here. > Thanks. > > David > > p.s. shouldn't include/aout/stab.def and gcc/stab.def be merged? Possibly. I would imagine that nobody seriously cares about *extending* STABS anymore, so nobody has had any motivation to do anything about it. --Dan ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-16 16:47 ` Daniel Berlin @ 2003-04-16 17:16 ` David Taylor 2003-04-16 17:25 ` Daniel Jacobowitz 2003-04-16 17:38 ` Andrew Cagney 0 siblings, 2 replies; 11+ messages in thread From: David Taylor @ 2003-04-16 17:16 UTC (permalink / raw) To: Daniel Berlin; +Cc: gcc, gdb > Date: Wed, 16 Apr 2003 12:47:17 -0400 > From: Daniel Berlin <dberlin@dberlin.org> > > On Wednesday, April 16, 2003, at 11:58 AM, David Taylor wrote: > > > The GCC side of things took less than a day to implement; I'm hoping > > to get started on the GDB side soon. > > > I didn't see it on the GCC list. Was it submitted? > I ask because ... Not yet. The copyright assignment paperwork for EMC's changes to GCC hasn't been approved/signed yet by management. I expect it will be approved/signed, but it hasn't been yet. [I feel that it is inappropriate to post changes if they are not assigned (unless they are small enough to not need an assignment). However, I do feel it is appropriate to discuss how to do it / what to name things / etc. as the changes are likely to be assigned.] Also, since the GDB part isn't done yet, the GCC part isn't particularly useful as yet. [NOTE: GDB copyright assignment papers *have* been signed.] > > One question I have is what stabs types to use -- tentatively I'm > > using: > > > > /* GNU extension. Macro define. */ > > __define_stab(N_MAC_DEFINE, 0x36, "MAC_DEFINE") > > > /* GNU extension. Macro undefine. */ > > __define_stab(N_MAC_UNDEF, 0x3a, "MAC_UNDEF") > > > Unless these are really generated by GCC, they aren't GNU extensions, > they are EMC extensions. You are correct that they are currently EMC extensions. After the change gets submitted, if it is accepted, then it will be a GNU extension. > > as it appears (based on gcc/stab.def, include/aout/stab.def, and > > gdb/doc/stabs.texinfo) that 0x36 and 0x3a are available. > > > > Is anyone aware of any other uses of stab types 0x36 and 0x3a -- > > i.e. is anyone aware of uses that might conflict? > > > You might want to look at what Sun's tools do. > Do they generate STABS anymore, and if so, see if they have extensions > that conflict here. I don't currently have access to Sun's tools. Also, Sun used to be (might still be for all I know) rather secretive about their stabs extensions. Does Sun document their stabs stuff in a publicly accessible document? I don't know if Sun's tools still generate stabs or not. > > Thanks. > > > > David > > > > p.s. shouldn't include/aout/stab.def and gcc/stab.def be merged? > > Possibly. > I would imagine that nobody seriously cares about *extending* STABS > anymore, so nobody has had any motivation to do anything about it. > > --Dan Later, David ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-16 17:16 ` David Taylor @ 2003-04-16 17:25 ` Daniel Jacobowitz 2003-04-16 17:38 ` Andrew Cagney 1 sibling, 0 replies; 11+ messages in thread From: Daniel Jacobowitz @ 2003-04-16 17:25 UTC (permalink / raw) To: David Taylor; +Cc: Daniel Berlin, gcc, gdb On Wed, Apr 16, 2003 at 01:16:20PM -0400, David Taylor wrote: > I don't currently have access to Sun's tools. Also, Sun used to be > (might still be for all I know) rather secretive about their stabs > extensions. Does Sun document their stabs stuff in a publicly > accessible document? They did as recently as 1999, and there is no mention of macros in the manual. I think it's on their website somewhere. > I don't know if Sun's tools still generate stabs or not. I believe they do. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-16 17:16 ` David Taylor 2003-04-16 17:25 ` Daniel Jacobowitz @ 2003-04-16 17:38 ` Andrew Cagney 1 sibling, 0 replies; 11+ messages in thread From: Andrew Cagney @ 2003-04-16 17:38 UTC (permalink / raw) To: David Taylor; +Cc: Daniel Berlin, gcc, gdb > Not yet. The copyright assignment paperwork for EMC's changes to GCC > hasn't been approved/signed yet by management. I expect it will be > approved/signed, but it hasn't been yet. > > [I feel that it is inappropriate to post changes if they are not > assigned (unless they are small enough to not need an assignment). This is really appreciated. > However, I do feel it is appropriate to discuss how to do it / what to > name things / etc. as the changes are likely to be assigned.] Yes. Technical aspects should be fleshed out up front. That way all parties concerned know what has been agreed to. Just leaves the small issue of implementation :-) Andrew ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-16 15:58 stabs and macro information David Taylor 2003-04-16 16:47 ` Daniel Berlin @ 2003-04-16 17:27 ` Daniel Jacobowitz 2003-04-16 17:59 ` David Taylor 2003-04-16 20:29 ` Daniel Berlin 2003-04-24 3:20 ` Jim Blandy 2 siblings, 2 replies; 11+ messages in thread From: Daniel Jacobowitz @ 2003-04-16 17:27 UTC (permalink / raw) To: David Taylor; +Cc: gcc, gdb On Wed, Apr 16, 2003 at 11:58:19AM -0400, David Taylor wrote: > Currently, when invoked with -gdwarf-2 -g3, gcc will record macro > information in a .debug_macinfo elf section. And when presented with > an executable containing macro information in a .debug_macinfo > section, gdb will make use of it. > > Many companies, including EMC, still use stabs. So... it would be > nice if the same was true of stabs. A more interesting question, to me, is why EMC still needs to use stabs. They are an inferior debug format, extremely hard to parse or extend. GCC's and GDB's current implementations of DWARF-2 (and 3) are somewhat lacking, but it's all fixable. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-16 17:27 ` Daniel Jacobowitz @ 2003-04-16 17:59 ` David Taylor 2003-04-16 20:29 ` Daniel Berlin 1 sibling, 0 replies; 11+ messages in thread From: David Taylor @ 2003-04-16 17:59 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gcc, gdb > Date: Wed, 16 Apr 2003 13:27:04 -0400 > From: Daniel Jacobowitz <drow@mvista.com> > > On Wed, Apr 16, 2003 at 11:58:19AM -0400, David Taylor wrote: > > Currently, when invoked with -gdwarf-2 -g3, gcc will record macro > > information in a .debug_macinfo elf section. And when presented with > > an executable containing macro information in a .debug_macinfo > > section, gdb will make use of it. > > > > Many companies, including EMC, still use stabs. So... it would be > > nice if the same was true of stabs. > > A more interesting question, to me, is why EMC still needs to use > stabs. They are an inferior debug format, extremely hard to parse or > extend. EMC does some processing of stabs via in house tools. I'm told that at one point before I started here that they switched to dwarf for a bit. And that the dwarf that was generated by GCC (and hence had to be handled by the local tools) changed a few times... They got tired of having to modify the in house tools, so they switched back to stabs. > GCC's and GDB's current implementations of DWARF-2 (and 3) are > somewhat lacking, but it's all fixable. I imagine we will eventually switch. But, as long as the gcc and gdb dwarf implementations are perceived as 'somewhat lacking', it's harder to make the case to management. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-16 17:27 ` Daniel Jacobowitz 2003-04-16 17:59 ` David Taylor @ 2003-04-16 20:29 ` Daniel Berlin 2003-04-17 16:39 ` David Taylor 1 sibling, 1 reply; 11+ messages in thread From: Daniel Berlin @ 2003-04-16 20:29 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: David Taylor, gcc, gdb On Wednesday, April 16, 2003, at 01:27 PM, Daniel Jacobowitz wrote: > On Wed, Apr 16, 2003 at 11:58:19AM -0400, David Taylor wrote: >> Currently, when invoked with -gdwarf-2 -g3, gcc will record macro >> information in a .debug_macinfo elf section. And when presented with >> an executable containing macro information in a .debug_macinfo >> section, gdb will make use of it. >> >> Many companies, including EMC, still use stabs. So... it would be >> nice if the same was true of stabs. > > A more interesting question, to me, is why EMC still needs to use > stabs. I didn't want to get into this argument, as there are companies that have valid reasons not to use DWARF2 given the current implementations, particularly those compaonies that end up with 1 gigabyte with stabs info, and 5 gigabytes with dwarf2 info, or something like that. However, I was going to ask whether the cost of *adding* more features to the STABS implementations in gdb and gcc is worth the future maintenance cost at this point in the life of STABS. > They are an inferior debug format, extremely hard to parse or > extend. GCC's and GDB's current implementations of DWARF-2 (and 3) are > somewhat lacking, but it's all fixable. And, more importantly, in the process of being fixed. :) > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-16 20:29 ` Daniel Berlin @ 2003-04-17 16:39 ` David Taylor 2003-04-17 16:46 ` Daniel Jacobowitz 0 siblings, 1 reply; 11+ messages in thread From: David Taylor @ 2003-04-17 16:39 UTC (permalink / raw) To: Daniel Berlin; +Cc: Daniel Jacobowitz, gcc, gdb > Date: Wed, 16 Apr 2003 16:29:54 -0400 > From: Daniel Berlin <dberlin@dberlin.org> > > On Wednesday, April 16, 2003, at 01:27 PM, Daniel Jacobowitz wrote: > > > A more interesting question, to me, is why EMC still needs to use > > stabs. > I didn't want to get into this argument, as there are companies that > have valid reasons not to use DWARF2 given the current implementations, > particularly those compaonies that end up with 1 gigabyte with stabs > info, and 5 gigabytes with dwarf2 info, or something like that. Agreed. I was talking earlier yesterday with the author of some of the internal tools that manipulate STABS. At least part of the reason for preferring STABS is the sheer size of the DWARF information. I believe that eliminating duplication of information so that DWARF is comparable in size to STABS will go a long way towards reducing people's resistance to DWARF. Stability in how information is encoded will also help. Another complaint I heard was how DWARF is a mixture of binary and text whereas STABS is just text -- therefore making STABS easier to parse by Perl. [I believe that the person making this complaint feels much more comfortable with Perl than with C.] > However, I was going to ask whether the cost of *adding* more features > to the STABS implementations in gdb and gcc is worth the future > maintenance cost at this point in the life of STABS. The GCC cost seems low. Factoring out the interrupts and related items that occurred during the implementation, testing, and debugging, I would guess that it was less than one day to do all three. Let's see, I modified 3 files, c-lex.c, dbxout.c, and stab.def. * c-lex.c (init_c_lex): Set cb->define and cb->undef for DBX_DEBUG, too. * dbxout.c (dbxout_define, dbxout_undef): New functions; handle macro define and undef for STABS. (dbx_debug_hooks): Initialize define and undef fields to dbxout_define and dbxout_undef, respectively. * stab.def (N_MAC_DEFINE, N_MAC_UNDEF): New entries. In c-lex.c, I modified 1 (one!) if statement to add DBX_DEBUG as a case where you want to initialize cb->define and cb->undef. Not a big deal. In stab.def, I've already posted the lines that got added. Also trivial. In dbxout.c, I added two simple functions and arranged for them to be called. Taking dbxout_define, here's how simple the body of it is: if (debug_info_level >= DINFO_LEVEL_VERBOSE) { fprintf (asmfile, "%s", ASM_STABS_OP); output_quoted_string (asmfile, buffer); fprintf (asmfile, ",%d,0,%d,0\n", N_MAC_DEFINE, lineno); } That is it. Nothing more. And dbxout_undef is *VERY* similar. Given how easy it is and given that I don't think that STABS is going to go away anytime soon, I think it's worth it. Perhaps I'm wrong. [But, it's worth it to us. And even if the change, when it's eventually posted, is not accepted, we will likely maintain this difference as long as we continue to use STABS.] > > They are an inferior debug format, extremely hard to parse or > > extend. GCC's and GDB's current implementations of DWARF-2 (and 3) are > > somewhat lacking, but it's all fixable. > > And, more importantly, in the process of being fixed. > :) Ummm, I would have to disagree about the first part. STABS is pretty easy to extend. I haven't done the GDB part yet; but, while I imagine it will take longer to do than the GCC part, I don't expect it to take a long time and I expect that the bulk of the time will be becoming enough familiar with the macro table stuff in GDB to make the right calls. How to modify GDB's STABS parser looks pretty straightforward. I think that a large part of STABS' problem, historically, is that . it was easy to extend, . there was no one charged with resolving conflicts between conflicting extensions, and . it was undocumented. [Because it was undocumented, in a conflict between a STABS producer and a STABS consumer, you couldn't say definitively who was right and who was wrong. We live with the result.] That the problems with GCC's and GDB's implementations of DWARF are being addressed is important. I feel that saying that DWARF is a superior *format* is irrelevant if the implementation is not superior. As the implementation improves and the size of the DWARF info decreases, people will be more likely to embrace DWARF. The size of the information is an issue for us. > > > > -- > > Daniel Jacobowitz > > MontaVista Software Debian GNU/Linux Developer Later, David -- David Taylor dtaylor@emc.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-17 16:39 ` David Taylor @ 2003-04-17 16:46 ` Daniel Jacobowitz 0 siblings, 0 replies; 11+ messages in thread From: Daniel Jacobowitz @ 2003-04-17 16:46 UTC (permalink / raw) To: David Taylor; +Cc: Daniel Berlin, gcc, gdb On Thu, Apr 17, 2003 at 12:39:21PM -0400, David Taylor wrote: > > > They are an inferior debug format, extremely hard to parse or > > > extend. GCC's and GDB's current implementations of DWARF-2 (and 3) are > > > somewhat lacking, but it's all fixable. > > > > And, more importantly, in the process of being fixed. > > :) > > Ummm, I would have to disagree about the first part. > > STABS is pretty easy to extend. I haven't done the GDB part yet; but, > while I imagine it will take longer to do than the GCC part, I don't > expect it to take a long time and I expect that the bulk of the time > will be becoming enough familiar with the macro table stuff in GDB to > make the right calls. How to modify GDB's STABS parser looks pretty > straightforward. No. Your extensions are an example of a kind which would be easy to add; but for some C++ concepts which DWARF-2 can express, it would be a heck of a lot harder. Inline functions, templates, namespaces (Sun has recent extensions for at least this one), virtual inheritance (we can do this now but you'll see what I mean about gross extensions if you look at how!), et cetera. A better example is .debug_loc; location lists in stabs would be extremely difficult to integrate into the stabs text format. > That the problems with GCC's and GDB's implementations of DWARF are > being addressed is important. > > I feel that saying that DWARF is a superior *format* is irrelevant if > the implementation is not superior. As the implementation improves > and the size of the DWARF info decreases, people will be more likely > to embrace DWARF. The size of the information is an issue for us. These are not the only implementations in the world. Sadly, right now they aren't close to the best, either. There are some interesting existance proofs, in e.g. the Intel tools. As for text vs binary - there are at least two good DWARF-2 dumpers, readelf and dwarfdump; I find their output a whole lot easier to make sense of than stabs. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: stabs and macro information 2003-04-16 15:58 stabs and macro information David Taylor 2003-04-16 16:47 ` Daniel Berlin 2003-04-16 17:27 ` Daniel Jacobowitz @ 2003-04-24 3:20 ` Jim Blandy 2 siblings, 0 replies; 11+ messages in thread From: Jim Blandy @ 2003-04-24 3:20 UTC (permalink / raw) To: David Taylor; +Cc: gcc, gdb David Taylor <dtaylor@emc.com> writes: > One question I have is what stabs types to use -- tentatively I'm using: > > /* GNU extension. Macro define. */ > __define_stab(N_MAC_DEFINE, 0x36, "MAC_DEFINE") > > /* GNU extension. Macro undefine. */ > __define_stab(N_MAC_UNDEF, 0x3a, "MAC_UNDEF") > > as it appears (based on gcc/stab.def, include/aout/stab.def, and > gdb/doc/stabs.texinfo) that 0x36 and 0x3a are available. > > Is anyone aware of any other uses of stab types 0x36 and 0x3a -- > i.e. is anyone aware of uses that might conflict? At least according to Version 4.0 of Sun's _Stabs Interface Manual_, dated February 1999, those numbers are not in use. The _Stabs Interface Manual_ is not available on the web. I wrote to Sun asking why it wasn't; they told me that it was included with the Sun toolchain, and was deliberately not available on the web. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-04-24 3:20 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-04-16 15:58 stabs and macro information David Taylor 2003-04-16 16:47 ` Daniel Berlin 2003-04-16 17:16 ` David Taylor 2003-04-16 17:25 ` Daniel Jacobowitz 2003-04-16 17:38 ` Andrew Cagney 2003-04-16 17:27 ` Daniel Jacobowitz 2003-04-16 17:59 ` David Taylor 2003-04-16 20:29 ` Daniel Berlin 2003-04-17 16:39 ` David Taylor 2003-04-17 16:46 ` Daniel Jacobowitz 2003-04-24 3:20 ` Jim Blandy
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).