* Re: GDB PATCH to disable specific G++ demangling
[not found] <Pine.LNX.4.10.10012180337180.15723-100000@www.cgsoftware.com>
@ 2000-12-19 6:39 ` Jason Merrill
2000-12-19 8:44 ` Daniel Berlin
0 siblings, 1 reply; 2+ messages in thread
From: Jason Merrill @ 2000-12-19 6:39 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Eli Zaretskii, gdb-patches
>>>>> "Daniel" == Daniel Berlin <dberlin@redhat.com> writes:
>>
>> Could you possibly say a few words about this change, and what exactly
>> is its effect, for those who don't know by heart what AUTO_DEMANGLING
>> does?
> AUTO_DEMANGLING detects the mangling style automatically, and demangles it
> based on that.
> This change defaults to doing this, now that we have two very different
> demangling styles about to common usage, and we previously defaulted to
> assuming we had one of these styles (the old abi mangling) if we
> determined it was a gcc compiled program, and we were using dwarf or
> stabs.
Yup.
> I would have fixed this before, but i mainly deal with dwarf2, which we
> default to AUTO_DEMANGLING.
Hmm, so do I, and I was still seeing mangled names before this patch. I
assumed that the dwarf2 code was using something out of stabsread, but
didn't bother tracking it down.
So, OK?
Jason
From jason@redhat.com Tue Dec 19 07:03:00 2000
From: Jason Merrill <jason@redhat.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: dberlin@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: GDB PATCH to disable specific G++ demangling
Date: Tue, 19 Dec 2000 07:03:00 -0000
Message-id: <u9snnkqwrh.fsf@casey.cambridge.redhat.com>
References: <Pine.LNX.4.10.10012180337180.15723-100000@www.cgsoftware.com> <200012191120.GAA12051@indy.delorie.com>
X-SW-Source: 2000-12/msg00231.html
Content-length: 1197
>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
>> Date: Mon, 18 Dec 2000 03:42:10 -0500 (EST)
>> From: Daniel Berlin <dberlin@redhat.com>
>>
>> AUTO_DEMANGLING detects the mangling style automatically, and demangles it
>> based on that.
>> This change defaults to doing this, now that we have two very different
>> demangling styles about to common usage, and we previously defaulted to
>> assuming we had one of these styles (the old abi mangling) if we
>> determined it was a gcc compiled program, and we were using dwarf or
>> stabs.
> Thanks for the explanations. I have one question, though: If
> AUTO_DEMANGLING can detect the mangling style, why was it not used
> previously? Why did the previous version trust the fact that it was
> looking at a GCC-compiled program more than it trusted auto-detection?
Because there was only the one GCC mangling scheme, so there was no reason
to be flexible. And AUTO_DEMANGLING is probably slightly slower.
> The change had to do with how GCC-compiled programs was recognized.
> The original code didn't get it right, in the DJGPP case. I forget
> the details, but can dust them off, if that's important.
I don't think it is.
Jason
From ezannoni@cygnus.com Tue Dec 19 07:40:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] another sh-tdep.c patch
Date: Tue, 19 Dec 2000 07:40:00 -0000
Message-id: <14911.33146.507917.193121@kwikemart.cygnus.com>
X-SW-Source: 2000-12/msg00232.html
Content-length: 1284
Just a little change:
2000-12-19 Elena Zannoni <ezannoni@kwikemart.cygnus.com>
* sh-tdep.c (sh_gdbarch_init): Move setting of breakpoint_from_pc
to before switch statement.
Index: sh-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sh-tdep.c,v
retrieving revision 1.23
diff -c -u -p -r1.23 sh-tdep.c
--- sh-tdep.c 2000/12/18 04:36:35 1.23
+++ sh-tdep.c 2000/12/19 15:39:46
@@ -1919,6 +1919,7 @@ sh_gdbarch_init (struct gdbarch_info inf
set_gdbarch_fetch_pseudo_register (gdbarch, sh_fetch_pseudo_register);
set_gdbarch_store_pseudo_register (gdbarch, sh_store_pseudo_register);
set_gdbarch_do_registers_info (gdbarch, sh_do_registers_info);
+ set_gdbarch_breakpoint_from_pc (gdbarch, sh_breakpoint_from_pc);
print_sh_insn = gdb_print_insn_sh;
switch (info.bfd_arch_info->mach)
@@ -2109,7 +2110,6 @@ sh_gdbarch_init (struct gdbarch_info inf
set_gdbarch_inner_than (gdbarch, core_addr_lessthan);
set_gdbarch_decr_pc_after_break (gdbarch, 0);
set_gdbarch_function_start_offset (gdbarch, 0);
- set_gdbarch_breakpoint_from_pc (gdbarch, sh_breakpoint_from_pc);
set_gdbarch_frame_args_skip (gdbarch, 0);
set_gdbarch_frameless_function_invocation (gdbarch, frameless_look_for_prologue);
From dan@cgsoftware.com Tue Dec 19 08:40:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Jason Merrill <jason@redhat.com>, Eli Zaretskii <eliz@is.elta.co.il>
Cc: Daniel Berlin <dberlin@redhat.com>, <gdb-patches@sources.redhat.com>
Subject: Re: GDB PATCH to disable specific G++ demangling
Date: Tue, 19 Dec 2000 08:40:00 -0000
Message-id: <B664F994.826%dan@cgsoftware.com>
References: <u9snnkqwrh.fsf@casey.cambridge.redhat.com>
X-SW-Source: 2000-12/msg00233.html
Content-length: 1419
On 12/19/00 10:02 AM, "Jason Merrill" <jason@redhat.com> wrote:
>>>>>> "Eli" == Eli Zaretskii <eliz@delorie.com> writes:
>
>>> Date: Mon, 18 Dec 2000 03:42:10 -0500 (EST)
>>> From: Daniel Berlin <dberlin@redhat.com>
>>>
>>> AUTO_DEMANGLING detects the mangling style automatically, and demangles it
>>> based on that.
>>> This change defaults to doing this, now that we have two very different
>>> demangling styles about to common usage, and we previously defaulted to
>>> assuming we had one of these styles (the old abi mangling) if we
>>> determined it was a gcc compiled program, and we were using dwarf or
>>> stabs.
>
>> Thanks for the explanations. I have one question, though: If
>> AUTO_DEMANGLING can detect the mangling style, why was it not used
>> previously? Why did the previous version trust the fact that it was
>> looking at a GCC-compiled program more than it trusted auto-detection?
>
> Because there was only the one GCC mangling scheme, so there was no reason
> to be flexible. And AUTO_DEMANGLING is probably slightly slower.
Yes, by a very small factor.
However, I don't know why this mattered enough for someone to have that code
there.
>
>> The change had to do with how GCC-compiled programs was recognized.
>> The original code didn't get it right, in the DJGPP case. I forget
>> the details, but can dust them off, if that's important.
>
> I don't think it is.
>
> Jason
>
^ permalink raw reply [flat|nested] 2+ messages in thread