> "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 e
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
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
ne
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 mai
> "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
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.
Ja
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.
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.
>
> P
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
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
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.
> "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
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 m
> "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
> 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
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 su
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 (d
> "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
> "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, p
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, ...)
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 in
> 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
> "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:
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
>
24 matches
Mail list logo
