Re: RFA: consolidate DWARF strings into libiberty
> "Tom" == Tom Tromey writes:
HJ> You should add extern "C" for C++ on those functions moved to
HJ> libiberty.
Tom> Yeah, sorry about that.
Tom> I'm testing the fix.
Here is what I am checking in.
Tom
ChangeLog:
2012-04-27 Tom Tromey
* dwarf2.h: Wrap function declarations in extern "C".
Index: dwarf2.h
===
--- dwarf2.h(revision 186908)
+++ dwarf2.h(working copy)
@@ -361,6 +361,10 @@
#define DW_EH_PE_indirect 0x80
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
/* Return the name of a DW_TAG_ constant, or NULL if the value is not
recognized. */
extern const char *get_DW_TAG_name (unsigned int tag);
@@ -385,4 +389,8 @@
recognized. */
extern const char *get_DW_CFA_name (unsigned int opc);
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
#endif /* _DWARF2_H */
Re: RFA: consolidate DWARF strings into libiberty
HJ> You should add extern "C" for C++ on those functions moved to HJ> libiberty. Yeah, sorry about that. I'm testing the fix. Tom
Re: RFA: consolidate DWARF strings into libiberty
On Fri, Apr 27, 2012 at 9:01 AM, H.J. Lu wrote: > On Fri, Apr 27, 2012 at 7:11 AM, Tom Tromey wrote: >>> "Jakub" == Jakub Jelinek writes: >> >> Jakub> On Thu, Apr 26, 2012 at 01:52:31PM -0400, DJ Delorie wrote: I will not oppose adding more unrelated stuff to libiberty, but neither will I approve it. I will let one of the other maintainers or a global maintainer approve it. >> >> Jakub> The original libiberty patch is ok for trunk then. >> >> Thanks, Jakub. I am checking it in to the gcc tree. >> I'll send the gdb and binutils follow-ups later. >> >> Tom > > This breaks GCC bootstrap: > > http://gcc.gnu.org/ml/gcc-regression/2012-04/msg00500.html > You should add extern "C" for C++ on those functions moved to libiberty. -- H.J.
Re: RFA: consolidate DWARF strings into libiberty
On Fri, Apr 27, 2012 at 7:11 AM, Tom Tromey wrote: >> "Jakub" == Jakub Jelinek writes: > > Jakub> On Thu, Apr 26, 2012 at 01:52:31PM -0400, DJ Delorie wrote: >>> >>> I will not oppose adding more unrelated stuff to libiberty, but >>> neither will I approve it. I will let one of the other maintainers or >>> a global maintainer approve it. > > Jakub> The original libiberty patch is ok for trunk then. > > Thanks, Jakub. I am checking it in to the gcc tree. > I'll send the gdb and binutils follow-ups later. > > Tom This breaks GCC bootstrap: http://gcc.gnu.org/ml/gcc-regression/2012-04/msg00500.html -- H.J.
Re: RFA: consolidate DWARF strings into libiberty
> "Jakub" == Jakub Jelinek writes: Jakub> On Thu, Apr 26, 2012 at 01:52:31PM -0400, DJ Delorie wrote: >> >> I will not oppose adding more unrelated stuff to libiberty, but >> neither will I approve it. I will let one of the other maintainers or >> a global maintainer approve it. Jakub> The original libiberty patch is ok for trunk then. Thanks, Jakub. I am checking it in to the gcc tree. I'll send the gdb and binutils follow-ups later. Tom
Re: RFA: consolidate DWARF strings into libiberty
On Thu, Apr 26, 2012 at 01:52:31PM -0400, DJ Delorie wrote: > > I will not oppose adding more unrelated stuff to libiberty, but > neither will I approve it. I will let one of the other maintainers or > a global maintainer approve it. The original libiberty patch is ok for trunk then. Jakub
Re: RFA: consolidate DWARF strings into libiberty
I will not oppose adding more unrelated stuff to libiberty, but neither will I approve it. I will let one of the other maintainers or a global maintainer approve it.
Re: RFA: consolidate DWARF strings into libiberty
On Mon, Apr 23, 2012 at 08:45:18AM -0600, Tom Tromey wrote: > Tom> Here is a new patch for gcc. > Tom> I still haven't updated the src side, but there's little to do there > Tom> that isn't already done in this patch. > > Tom> Ok? > > Tom> Ping. > > Tom> Ping. > > This is the third ping. > > Please review the patch. > > There are two choices: > > 1. Approve the original patch, adding a file to libiberty. >Given how much code in libiberty is already unrelated to portability, >I would say this is the simplest route. >From a quick glance -- concat.c, the demangler, crc32.c, >dyn-string.c, fdmatch.c, fibheap.c, hashtab.c, hex.c, md5.c, >objalloc.c, obstack.c, sha1.c, simple-object*. Yeah, that would be my preference. libiberty is already a kitchen sink, has been handled that way for many years, and creating a new kitchen sink library is both overkill and will not make it a kitchen sink if only this dwarf strings stuff is added to that and all the other kitchen sink stuff stays in libiberty. Jakub
Re: RFA: consolidate DWARF strings into libiberty
Tom> Here is a new patch for gcc. Tom> I still haven't updated the src side, but there's little to do there Tom> that isn't already done in this patch. Tom> Ok? Tom> Ping. Tom> Ping. This is the third ping. Please review the patch. There are two choices: 1. Approve the original patch, adding a file to libiberty. Given how much code in libiberty is already unrelated to portability, I would say this is the simplest route. From a quick glance -- concat.c, the demangler, crc32.c, dyn-string.c, fdmatch.c, fibheap.c, hashtab.c, hex.c, md5.c, objalloc.c, obstack.c, sha1.c, simple-object*. 2. Approve the new patch adding libksink. thanks, Tom
Re: RFA: consolidate DWARF strings into libiberty
Tom> Here is a new patch for gcc. Tom> I still haven't updated the src side, but there's little to do there Tom> that isn't already done in this patch. Tom> Ok? Tom> Ping. Ping. Tom
Re: RFA: consolidate DWARF strings into libiberty
Hi Tom, Built and regtested on x86-64 Fedora 16. Ok? Tom 2012-03-15 Tom Tromey * dwarf2out.c (dwarf_stack_op_name): Use get_DW_OP_name. (dwarf_tag_name): Use get_DW_TAG_name. (dwarf_attr_name): Use get_DW_AT_name. (dwarf_form_name): Use get_DW_FORM_name. * dwarf2cfi.c (dwarf_cfi_name): Use get_DW_CFA_name. 2012-03-15 Tom Tromey * dwarf2.h (enum dwarf_tag, enum dwarf_form, enum dwarf_attribute) (enum dwarf_location_atom, enum dwarf_type, enum dwarf_call_frame_info): Remove. (DW_TAG, DW_TAG_DUP, DW_FORM, DW_AT, DW_AT_DUP, DW_OP) (DW_OP_DUP, DW_ATE, DW_ATE_DUP, DW_CFA): New macros. Include dwarf2.def. (get_DW_TAG_name, get_DW_AT_name, get_DW_FORM_name) (get_DW_OP_name, get_DW_ATE_name): Declare. * dwarf2.def: New file, from dwarf2.h. 2012-03-15 Tom Tromey * dwarfnames.c: New file. * Makefile.in (CFILES): Add dwarfnames. (REQUIRED_OFILES): Add dwarfnames. (./dwarfnames.$(objext)): New target. This is OK from a binutils point of view. Cheers Nick
Re: RFA: consolidate DWARF strings into libiberty
> "Tom" == Tom Tromey writes: Tom> Here is a new patch for gcc. Tom> I still haven't updated the src side, but there's little to do there Tom> that isn't already done in this patch. Tom> Ok? Ping. Tom
Re: RFA: consolidate DWARF strings into libiberty
On Mon, Mar 19, 2012 at 9:09 AM, Doug Evans wrote: > On Thu, Mar 15, 2012 at 12:02 PM, Tom Tromey wrote: >>> "DJ" == DJ Delorie writes: >> >> Tom> Finally, there is already stuff in libiberty not related to >> Tom> portability. E.g., hashtab or the demangler. >> >> DJ> Yeah, I know, hence my "Should I give up that premise?" >> >> Yeah. >> >> I am not sure there will ever be enough shared code to warrant a new >> library, particularly because adding a new library is so expensive -- >> not just the configury stuff but also adding it to the link lines in the >> Makefiles of all the tools that might need it. >> >> I suppose if I had my wish list implemented here, it would be to remove >> the portability stuff from libiberty in favor of gnulib, and keep >> libiberty as a higher-level library. > > That won't really fix libiberty being an ever growing kitchen sink. > > How hard would it really be to make it easier to add new libraries? > It's not like we're expecting 100. > But given the pushback for even one new library, I think we're > unnecessarily slowing ourselves down. btw, While I like using gnulib more, do we know it will necessarily always solve portability problems in a timely manner? I wouldn't mind keeping libiberty as a fallback. Plus, some of the complexity of libiberty is supporting all of $build,$host,$target in one build. The utilities I think you're thinking of adding (or at least the utilities I've come across as wanting to add to a more useful location) are just for the tools (i.e. $host). Putting them in libiberty doesn't "feel right".
Re: RFA: consolidate DWARF strings into libiberty
> "DJ" == DJ Delorie writes: DJ> The only drawback to adding toplevel libraries is coordinating changes DJ> among the toplevel configury. And adding crud to Makefiles all over. Pick a name for the new library and I will implement this. Tom
Re: RFA: consolidate DWARF strings into libiberty
> But given the pushback for even one new library, I think we're > unnecessarily slowing ourselves down. I'm not opposed to libiberty becoming the kitchen sink, if that's what people want. If it does go that route, my reason for being a libiberty maintainer no longer applies, and others who are more kitchen-sink-minded should take over. The only drawback to adding toplevel libraries is coordinating changes among the toplevel configury.
Re: RFA: consolidate DWARF strings into libiberty
On Thu, Mar 15, 2012 at 12:02 PM, Tom Tromey wrote: >> "DJ" == DJ Delorie writes: > > Tom> Finally, there is already stuff in libiberty not related to > Tom> portability. E.g., hashtab or the demangler. > > DJ> Yeah, I know, hence my "Should I give up that premise?" > > Yeah. > > I am not sure there will ever be enough shared code to warrant a new > library, particularly because adding a new library is so expensive -- > not just the configury stuff but also adding it to the link lines in the > Makefiles of all the tools that might need it. > > I suppose if I had my wish list implemented here, it would be to remove > the portability stuff from libiberty in favor of gnulib, and keep > libiberty as a higher-level library. That won't really fix libiberty being an ever growing kitchen sink. How hard would it really be to make it easier to add new libraries? It's not like we're expecting 100. But given the pushback for even one new library, I think we're unnecessarily slowing ourselves down.
Re: RFA: consolidate DWARF strings into libiberty
On 03/15/12 12:29, Tom Tromey wrote: > 2012-03-15 Tom Tromey > > * dwarf2out.c (dwarf_stack_op_name): Use get_DW_OP_name. > (dwarf_tag_name): Use get_DW_TAG_name. > (dwarf_attr_name): Use get_DW_AT_name. > (dwarf_form_name): Use get_DW_FORM_name. > * dwarf2cfi.c (dwarf_cfi_name): Use get_DW_CFA_name. Gcc parts ok. r~
Re: RFA: consolidate DWARF strings into libiberty
> "Jakub" == Jakub Jelinek writes: Jakub> On Thu, Mar 15, 2012 at 12:41:54PM -0600, Tom Tromey wrote: >> I guess I can just put the whole DW_TAG_ prefix in there. >> That isn't a big deal. Or if you have some other suggestion, I can >> implement it. Jakub> Yeah, I think the either the whole OP_TAG (DW_TAG_foobar, ...), or Jakub> OP_TAG (TAG_foobar, ...) would be safer and nicer. Ok, no problem. I will make that change. Tom
Re: RFA: consolidate DWARF strings into libiberty
> "DJ" == DJ Delorie writes: Tom> Finally, there is already stuff in libiberty not related to Tom> portability. E.g., hashtab or the demangler. DJ> Yeah, I know, hence my "Should I give up that premise?" Yeah. I am not sure there will ever be enough shared code to warrant a new library, particularly because adding a new library is so expensive -- not just the configury stuff but also adding it to the link lines in the Makefiles of all the tools that might need it. I suppose if I had my wish list implemented here, it would be to remove the portability stuff from libiberty in favor of gnulib, and keep libiberty as a higher-level library. Tom> I guess I can just put the whole DW_TAG_ prefix in there. That Tom> isn't a big deal. Or if you have some other suggestion, I can Tom> implement it. DJ> If the macros always prepend something to it, it should be safe DJ> enough, despite technically violating the spirit of the rule. I have DJ> no other suggestions. DJ> But given you've already had the issue with "and", you're already DJ> seeing problems anyway, so maybe that's a sign that it's not actually DJ> "safe enough" ? I think this arises from a bug in cpp, since it issues the -Wc++-compat warning even if the token in question is only used as an argument to stringizing. This seems mistaken -- but it seemed advisable to work around it. Tom
Re: RFA: consolidate DWARF strings into libiberty
On Thu, Mar 15, 2012 at 12:41:54PM -0600, Tom Tromey wrote: > I guess I can just put the whole DW_TAG_ prefix in there. > That isn't a big deal. Or if you have some other suggestion, I can > implement it. Yeah, I think the either the whole OP_TAG (DW_TAG_foobar, ...), or OP_TAG (TAG_foobar, ...) would be safer and nicer. Jakub
Re: RFA: consolidate DWARF strings into libiberty
On 03/15/2012 06:48 PM, DJ Delorie wrote: >> Finally, there is already stuff in libiberty not related to >> > portability. E.g., hashtab or the demangler. > Yeah, I know, hence my "Should I give up that premise?" Wouldn't it make sense to eventually switch everything to gnulib for portability instead? With that in mind, I predict we'll end up with libiberty composed of only the odd stuff. :-) -- Pedro Alves
Re: RFA: consolidate DWARF strings into libiberty
> Finally, there is already stuff in libiberty not related to > portability. E.g., hashtab or the demangler. Yeah, I know, hence my "Should I give up that premise?" > I guess I can just put the whole DW_TAG_ prefix in there. That > isn't a big deal. Or if you have some other suggestion, I can > implement it. If the macros always prepend something to it, it should be safe enough, despite technically violating the spirit of the rule. I have no other suggestions. But given you've already had the issue with "and", you're already seeing problems anyway, so maybe that's a sign that it's not actually "safe enough" ?
Re: RFA: consolidate DWARF strings into libiberty
> "DJ" == DJ Delorie writes: DJ> Sigh, libiberty is supposed to be a portability library, not a DJ> kitchen-sink for common stuff. Should I give up that premise? Or DJ> should we consider a common dwarf2 helper library, and move even more DJ> of the dwarf2 code into it? My reasoning was: I would have put it somewhere else, but there is nowhere else to put it. Making a new library for this one file seemed like overkill. Finally, there is already stuff in libiberty not related to portability. E.g., hashtab or the demangler. Tom> First, you'll notice that the first constant for a given enum is Tom> defined using a separate macro name. I couldn't think of a better Tom> way to avoid the "trailing ',' in an enum" warning -- one element Tom> must be distinguished, so I chose the first. DJ> I typically terminate the list with a "FOO_MAX" enum, which is going DJ> to need to be handled differently anyway. I usually do that to, but I wanted this change not to affect the contents of the defined enums. Tom> Also, you'll see that the names passed to the macros start with an "_". DJ> Beware you're not violating (or causing to violate) some ISO namespace DJ> requirement for identifiers starting with underscores. Yeah, I didn't consider that. I guess I can just put the whole DW_TAG_ prefix in there. That isn't a big deal. Or if you have some other suggestion, I can implement it. Tom
Re: RFA: consolidate DWARF strings into libiberty
Sigh, libiberty is supposed to be a portability library, not a kitchen-sink for common stuff. Should I give up that premise? Or should we consider a common dwarf2 helper library, and move even more of the dwarf2 code into it? > First, you'll notice that the first constant for a given enum is > defined using a separate macro name. I couldn't think of a better > way to avoid the "trailing ',' in an enum" warning -- one element > must be distinguished, so I chose the first. I typically terminate the list with a "FOO_MAX" enum, which is going to need to be handled differently anyway. > Also, you'll see that the names passed to the macros start with an "_". Beware you're not violating (or causing to violate) some ISO namespace requirement for identifiers starting with underscores.
