Re: GDB PATCH to disable specific G++ demangling

Re: GDB PATCH to disable specific G++ demangling

[Jason Merrill]

>>>>> "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
> 

Re: GDB PATCH to disable specific G++ demangling

[Daniel Berlin]

On 12/19/00 9:37 AM, "Jason Merrill" <jason@redhat.com> wrote:

>>>>>> "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.

Hmmm. I bet your libstdc++ or something had STABS debug info in it, which
would result in executables with both stabs, and dwarf2, and exhibit the
problem.



> 
> So, OK?

As far as I am concerned, as C++ support maintainer, but it's not my call. I
believe Jim Blandy is the STABS/DWARF2 reader person, without the
MAINTAINERS file sitting in front of me.

--Dan