* [PATCH]: C++ mangling patch that is about to be committed
@ 2000-10-10 7:20 Daniel Berlin
2000-10-10 8:29 ` Elena Zannoni
0 siblings, 1 reply; 7+ messages in thread
From: Daniel Berlin @ 2000-10-10 7:20 UTC (permalink / raw)
To: gdb-patches
I'm committing the following patch later today.
I'm also going to start moving these types of C++ specific routines
into cp-support.c and cp-support.h, rather than spread across 20
files, so it's clearer that they are C++ specific, and fall under the
maintainership of the C++ maintainer. It'll also give other
maintainers less they feel they have to worry about, since they really
shouldn't have to deal with things like gdb_mangle_name.
* symtab.h (OPNAME_PREFIX_P): Change operator prefix to correct value.
* symtab.c (gdb_mangle_name): Properly handle operators.
Index: symtab.c
===================================================================
RCS file: /cvs/src/src/gdb/symtab.c,v
retrieving revision 1.15
diff -c -3 -p -w -B -b -r1.15 symtab.c
*** symtab.c 2000/09/04 08:29:25 1.15
--- symtab.c 2000/09/12 16:03:08
*************** gdb_mangle_name (struct type *type, int
*** 296,301 ****
--- 303,311 ----
char buf[20];
int len = (newname == NULL ? 0 : strlen (newname));
+ if (OPNAME_PREFIX_P (field_name))
+ return physname;
+
is_full_physname_constructor =
((physname[0] == '_' && physname[1] == '_' &&
(isdigit (physname[2]) || physname[2] == 'Q' || physname[2] == 't'))
*************** gdb_mangle_name (struct type *type, int
*** 331,355 ****
sprintf (buf, "__%s%s%d", const_prefix, volatile_prefix, len);
}
mangled_name_len = ((is_constructor ? 0 : strlen (field_name))
! + strlen (buf) + len
! + strlen (physname)
! + 1);
!
! /* Only needed for GNU-mangled names. ANSI-mangled names
! work with the normal mechanisms. */
! if (OPNAME_PREFIX_P (field_name))
! {
! const char *opname = cplus_mangle_opname (field_name + 3, 0);
! if (opname == NULL)
! error ("No mangling for \"%s\"", field_name);
! mangled_name_len += strlen (opname);
! mangled_name = (char *) xmalloc (mangled_name_len);
- strncpy (mangled_name, field_name, 3);
- mangled_name[3] = '\0';
- strcat (mangled_name, opname);
- }
- else
{
mangled_name = (char *) xmalloc (mangled_name_len);
if (is_constructor)
--- 341,348 ----
sprintf (buf, "__%s%s%d", const_prefix, volatile_prefix, len);
}
mangled_name_len = ((is_constructor ? 0 : strlen (field_name))
! + strlen (buf) + len + strlen (physname) + 1);
{
mangled_name = (char *) xmalloc (mangled_name_len);
if (is_constructor)
Index: symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.13
diff -c -3 -p -r1.13 symtab.h
*** symtab.h 2000/08/07 15:02:48 1.13
--- symtab.h 2000/10/10 01:39:57
*************** extern CORE_ADDR symbol_overlayed_addres
*** 168,175 ****
specified obstack. */
#define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
! do { \ char *demangled = NULL; \
if (SYMBOL_LANGUAGE (symbol) == language_cplus \
|| SYMBOL_LANGUAGE (symbol) == language_auto) \
{ \--- 168,177 ----
specified obstack. */
#define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
! { \
char *demangled = NULL; \
+ if (SYMBOL_LANGUAGE (symbol) == language_unknown) \
+ SYMBOL_LANGUAGE(symbol) = language_auto; \
if (SYMBOL_LANGUAGE (symbol) == language_cplus \
|| SYMBOL_LANGUAGE (symbol) == language_auto) \
{ \*************** extern CORE_ADDR symbol_overlayed_addres
*** 222,232 ****
SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL; \
} \
} \! if (SYMBOL_LANGUAGE (symbol) == language_auto) \
! { \! SYMBOL_LANGUAGE (symbol) = language_unknown; \
! } \! } while (0)
/* Macro that returns the demangled name for a symbol based on the language
for that symbol. If no demangled name exists, returns NULL. */
--- 224,230 ----
SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL; \
} \
} \! }
/* Macro that returns the demangled name for a symbol based on the language
for that symbol. If no demangled name exists, returns NULL. */
*************** struct partial_symtab
*** 1047,1059 ****
#define VTBL_FNADDR_OFFSET 2
/* Macro that yields non-zero value iff NAME is the prefix for C++ operator
! names. If you leave out the parenthesis here you will lose!
! Currently 'o' 'p' CPLUS_MARKER is used for both the symbol in the
! symbol-file and the names in gdb's symbol table.
! Note that this macro is g++ specific (FIXME). */
!
#define OPNAME_PREFIX_P(NAME) \
! ((NAME)[0] == 'o' && (NAME)[1] == 'p' && is_cplus_marker ((NAME)[2]))
/* Macro that yields non-zero value iff NAME is the prefix for C++ vtbl
names. Note that this macro is g++ specific (FIXME).
--- 1045,1053 ----
#define VTBL_FNADDR_OFFSET 2
/* Macro that yields non-zero value iff NAME is the prefix for C++ operator
! names. If you leave out the parenthesis here you will lose! */
#define OPNAME_PREFIX_P(NAME) \
! (!strncmp(NAME,"operator",8))
/* Macro that yields non-zero value iff NAME is the prefix for C++ vtbl
names. Note that this macro is g++ specific (FIXME).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH]: C++ mangling patch that is about to be committed
2000-10-10 7:20 [PATCH]: C++ mangling patch that is about to be committed Daniel Berlin
@ 2000-10-10 8:29 ` Elena Zannoni
[not found] ` <m3k8bgadxp.fsf@dan2.cygnus.com>
0 siblings, 1 reply; 7+ messages in thread
From: Elena Zannoni @ 2000-10-10 8:29 UTC (permalink / raw)
To: Daniel Berlin; +Cc: gdb-patches
Daniel,
There is an extra change in symtab.h that has nothing to do with the
changelog. I think that is part of a different patch. BTW, I thought
we agreed to leave the do--while construct in the
SYMBOL_INIT_DEMANGLED_NAME macro.
Elena
Daniel Berlin writes:
> I'm committing the following patch later today.
>
> I'm also going to start moving these types of C++ specific routines
> into cp-support.c and cp-support.h, rather than spread across 20
> files, so it's clearer that they are C++ specific, and fall under the
> maintainership of the C++ maintainer. It'll also give other
> maintainers less they feel they have to worry about, since they really
> shouldn't have to deal with things like gdb_mangle_name.
>
> * symtab.h (OPNAME_PREFIX_P): Change operator prefix to correct value.
>
> * symtab.c (gdb_mangle_name): Properly handle operators.
>
>
> Index: symtab.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.c,v
> retrieving revision 1.15
> diff -c -3 -p -w -B -b -r1.15 symtab.c
> *** symtab.c 2000/09/04 08:29:25 1.15
> --- symtab.c 2000/09/12 16:03:08
> *************** gdb_mangle_name (struct type *type, int
> *** 296,301 ****
> --- 303,311 ----
> char buf[20];
> int len = (newname == NULL ? 0 : strlen (newname));
>
> + if (OPNAME_PREFIX_P (field_name))
> + return physname;
> +
> is_full_physname_constructor =
> ((physname[0] == '_' && physname[1] == '_' &&
> (isdigit (physname[2]) || physname[2] == 'Q' || physname[2] == 't'))
> *************** gdb_mangle_name (struct type *type, int
> *** 331,355 ****
> sprintf (buf, "__%s%s%d", const_prefix, volatile_prefix, len);
> }
> mangled_name_len = ((is_constructor ? 0 : strlen (field_name))
> ! + strlen (buf) + len
> ! + strlen (physname)
> ! + 1);
> !
> ! /* Only needed for GNU-mangled names. ANSI-mangled names
> ! work with the normal mechanisms. */
> ! if (OPNAME_PREFIX_P (field_name))
> ! {
> ! const char *opname = cplus_mangle_opname (field_name + 3, 0);
> ! if (opname == NULL)
> ! error ("No mangling for \"%s\"", field_name);
> ! mangled_name_len += strlen (opname);
> ! mangled_name = (char *) xmalloc (mangled_name_len);
>
> - strncpy (mangled_name, field_name, 3);
> - mangled_name[3] = '\0';
> - strcat (mangled_name, opname);
> - }
> - else
> {
> mangled_name = (char *) xmalloc (mangled_name_len);
> if (is_constructor)
> --- 341,348 ----
> sprintf (buf, "__%s%s%d", const_prefix, volatile_prefix, len);
> }
> mangled_name_len = ((is_constructor ? 0 : strlen (field_name))
> ! + strlen (buf) + len + strlen (physname) + 1);
>
> {
> mangled_name = (char *) xmalloc (mangled_name_len);
> if (is_constructor)
>
> Index: symtab.h
> ===================================================================
> RCS file: /cvs/src/src/gdb/symtab.h,v
> retrieving revision 1.13
> diff -c -3 -p -r1.13 symtab.h
> *** symtab.h 2000/08/07 15:02:48 1.13
> --- symtab.h 2000/10/10 01:39:57
> *************** extern CORE_ADDR symbol_overlayed_addres
> *** 168,175 ****
> specified obstack. */
>
> #define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
> ! do { \ char *demangled = NULL; \
> if (SYMBOL_LANGUAGE (symbol) == language_cplus \
> || SYMBOL_LANGUAGE (symbol) == language_auto) \
> { \--- 168,177 ----
> specified obstack. */
>
> #define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
> ! { \
> char *demangled = NULL; \
> + if (SYMBOL_LANGUAGE (symbol) == language_unknown) \
> + SYMBOL_LANGUAGE(symbol) = language_auto; \
> if (SYMBOL_LANGUAGE (symbol) == language_cplus \
> || SYMBOL_LANGUAGE (symbol) == language_auto) \
> { \*************** extern CORE_ADDR symbol_overlayed_addres
> *** 222,232 ****
> SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL; \
> } \
> } \! if (SYMBOL_LANGUAGE (symbol) == language_auto) \
> ! { \! SYMBOL_LANGUAGE (symbol) = language_unknown; \
> ! } \! } while (0)
>
> /* Macro that returns the demangled name for a symbol based on the language
> for that symbol. If no demangled name exists, returns NULL. */
> --- 224,230 ----
> SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL; \
> } \
> } \! }
>
> /* Macro that returns the demangled name for a symbol based on the language
> for that symbol. If no demangled name exists, returns NULL. */
> *************** struct partial_symtab
> *** 1047,1059 ****
> #define VTBL_FNADDR_OFFSET 2
>
> /* Macro that yields non-zero value iff NAME is the prefix for C++ operator
> ! names. If you leave out the parenthesis here you will lose!
> ! Currently 'o' 'p' CPLUS_MARKER is used for both the symbol in the
> ! symbol-file and the names in gdb's symbol table.
> ! Note that this macro is g++ specific (FIXME). */
> !
> #define OPNAME_PREFIX_P(NAME) \
> ! ((NAME)[0] == 'o' && (NAME)[1] == 'p' && is_cplus_marker ((NAME)[2]))
>
> /* Macro that yields non-zero value iff NAME is the prefix for C++ vtbl
> names. Note that this macro is g++ specific (FIXME).
> --- 1045,1053 ----
> #define VTBL_FNADDR_OFFSET 2
>
> /* Macro that yields non-zero value iff NAME is the prefix for C++ operator
> ! names. If you leave out the parenthesis here you will lose! */
> #define OPNAME_PREFIX_P(NAME) \
> ! (!strncmp(NAME,"operator",8))
>
> /* Macro that yields non-zero value iff NAME is the prefix for C++ vtbl
> names. Note that this macro is g++ specific (FIXME).
>
From dberlin@redhat.com Tue Oct 10 08:55:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 08:55:00 -0000
Message-id: <m3k8bgadxp.fsf@dan2.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com>
X-SW-Source: 2000-10/msg00040.html
Content-length: 7434
Elena Zannoni <ezannoni@cygnus.com> writes:
> Daniel,
>
> There is an extra change in symtab.h that has nothing to do with the
> changelog. I think that is part of a different patch.
No, I missed the changelog entry for it, stupidly.
> BTW, I thought
> we agreed to leave the do--while construct in the
> SYMBOL_INIT_DEMANGLED_NAME macro.
I'd rather not.
It's not used in if statements, and *never* should be.
The argument that someone, someday, might want to, just isn't
convincing, because they shouldn't.
>
> Elena
>
> Daniel Berlin writes:
> > I'm committing the following patch later today.
> >
> > I'm also going to start moving these types of C++ specific routines
> > into cp-support.c and cp-support.h, rather than spread across 20
> > files, so it's clearer that they are C++ specific, and fall under the
> > maintainership of the C++ maintainer. It'll also give other
> > maintainers less they feel they have to worry about, since they really
> > shouldn't have to deal with things like gdb_mangle_name.
> >
> > * symtab.h (OPNAME_PREFIX_P): Change operator prefix to correct value.
> >
> > * symtab.c (gdb_mangle_name): Properly handle operators.
> >
> >
> > Index: symtab.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/symtab.c,v
> > retrieving revision 1.15
> > diff -c -3 -p -w -B -b -r1.15 symtab.c
> > *** symtab.c 2000/09/04 08:29:25 1.15
> > --- symtab.c 2000/09/12 16:03:08
> > *************** gdb_mangle_name (struct type *type, int
> > *** 296,301 ****
> > --- 303,311 ----
> > char buf[20];
> > int len = (newname == NULL ? 0 : strlen (newname));
> >
> > + if (OPNAME_PREFIX_P (field_name))
> > + return physname;
> > +
> > is_full_physname_constructor =
> > ((physname[0] == '_' && physname[1] == '_' &&
> > (isdigit (physname[2]) || physname[2] == 'Q' || physname[2] == 't'))
> > *************** gdb_mangle_name (struct type *type, int
> > *** 331,355 ****
> > sprintf (buf, "__%s%s%d", const_prefix, volatile_prefix, len);
> > }
> > mangled_name_len = ((is_constructor ? 0 : strlen (field_name))
> > ! + strlen (buf) + len
> > ! + strlen (physname)
> > ! + 1);
> > !
> > ! /* Only needed for GNU-mangled names. ANSI-mangled names
> > ! work with the normal mechanisms. */
> > ! if (OPNAME_PREFIX_P (field_name))
> > ! {
> > ! const char *opname = cplus_mangle_opname (field_name + 3, 0);
> > ! if (opname == NULL)
> > ! error ("No mangling for \"%s\"", field_name);
> > ! mangled_name_len += strlen (opname);
> > ! mangled_name = (char *) xmalloc (mangled_name_len);
> >
> > - strncpy (mangled_name, field_name, 3);
> > - mangled_name[3] = '\0';
> > - strcat (mangled_name, opname);
> > - }
> > - else
> > {
> > mangled_name = (char *) xmalloc (mangled_name_len);
> > if (is_constructor)
> > --- 341,348 ----
> > sprintf (buf, "__%s%s%d", const_prefix, volatile_prefix, len);
> > }
> > mangled_name_len = ((is_constructor ? 0 : strlen (field_name))
> > ! + strlen (buf) + len + strlen (physname) + 1);
> >
> > {
> > mangled_name = (char *) xmalloc (mangled_name_len);
> > if (is_constructor)
> >
> > Index: symtab.h
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/symtab.h,v
> > retrieving revision 1.13
> > diff -c -3 -p -r1.13 symtab.h
> > *** symtab.h 2000/08/07 15:02:48 1.13
> > --- symtab.h 2000/10/10 01:39:57
> > *************** extern CORE_ADDR symbol_overlayed_addres
> > *** 168,175 ****
> > specified obstack. */
> >
> > #define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
> > ! do { \ char *demangled = NULL; \
> > if (SYMBOL_LANGUAGE (symbol) == language_cplus \
> > || SYMBOL_LANGUAGE (symbol) == language_auto) \
> > { \--- 168,177 ----
> > specified obstack. */
> >
> > #define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
> > ! { \
> > char *demangled = NULL; \
> > + if (SYMBOL_LANGUAGE (symbol) == language_unknown) \
> > + SYMBOL_LANGUAGE(symbol) = language_auto; \
> > if (SYMBOL_LANGUAGE (symbol) == language_cplus \
> > || SYMBOL_LANGUAGE (symbol) == language_auto) \
> > { \*************** extern CORE_ADDR symbol_overlayed_addres
> > *** 222,232 ****
> > SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL; \
> > } \
> > } \! if (SYMBOL_LANGUAGE (symbol) == language_auto) \
> > ! { \! SYMBOL_LANGUAGE (symbol) = language_unknown; \
> > ! } \! } while (0)
> >
> > /* Macro that returns the demangled name for a symbol based on the language
> > for that symbol. If no demangled name exists, returns NULL. */
> > --- 224,230 ----
> > SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL; \
> > } \
> > } \! }
> >
> > /* Macro that returns the demangled name for a symbol based on the language
> > for that symbol. If no demangled name exists, returns NULL. */
> > *************** struct partial_symtab
> > *** 1047,1059 ****
> > #define VTBL_FNADDR_OFFSET 2
> >
> > /* Macro that yields non-zero value iff NAME is the prefix for C++ operator
> > ! names. If you leave out the parenthesis here you will lose!
> > ! Currently 'o' 'p' CPLUS_MARKER is used for both the symbol in the
> > ! symbol-file and the names in gdb's symbol table.
> > ! Note that this macro is g++ specific (FIXME). */
> > !
> > #define OPNAME_PREFIX_P(NAME) \
> > ! ((NAME)[0] == 'o' && (NAME)[1] == 'p' && is_cplus_marker ((NAME)[2]))
> >
> > /* Macro that yields non-zero value iff NAME is the prefix for C++ vtbl
> > names. Note that this macro is g++ specific (FIXME).
> > --- 1045,1053 ----
> > #define VTBL_FNADDR_OFFSET 2
> >
> > /* Macro that yields non-zero value iff NAME is the prefix for C++ operator
> > ! names. If you leave out the parenthesis here you will lose! */
> > #define OPNAME_PREFIX_P(NAME) \
> > ! (!strncmp(NAME,"operator",8))
> >
> > /* Macro that yields non-zero value iff NAME is the prefix for C++ vtbl
> > names. Note that this macro is g++ specific (FIXME).
> >
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH]: C++ mangling patch that is about to be committed
[not found] ` <m3k8bgadxp.fsf@dan2.cygnus.com>
@ 2000-10-10 10:38 ` Kevin Buettner
[not found] ` <m38zrwa832.fsf@dan2.cygnus.com>
2000-10-10 11:25 ` Michael Snyder
1 sibling, 1 reply; 7+ messages in thread
From: Kevin Buettner @ 2000-10-10 10:38 UTC (permalink / raw)
To: Daniel Berlin, Elena Zannoni; +Cc: gdb-patches
On Oct 10, 11:55am, Daniel Berlin wrote:
> Elena Zannoni <ezannoni@cygnus.com> writes:
>
> > BTW, I thought
> > we agreed to leave the do--while construct in the
> > SYMBOL_INIT_DEMANGLED_NAME macro.
> I'd rather not.
> It's not used in if statements, and *never* should be.
> The argument that someone, someday, might want to, just isn't
> convincing, because they shouldn't.
Daniel,
This is really not the way to handle this kind of change. Elena is
right. The consensus was to leave the ``do ... while (0)'' construct
in the SYMBOL_INIT_DEMANGLED_NAME macro. I believe that turning it
into a proper function was also discussed and is regarded as a viable,
perhaps even superior, alternative.
I know that you don't like the do ... while (0) construct, but it is
not right for you to try to sneak changes eliminating it past the
maintainer multiple times, particularly when you agreed to leave it
in.
Kevin
From ezannoni@cygnus.com Tue Oct 10 10:48:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Daniel Berlin <dberlin@redhat.com>, Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 10:48:00 -0000
Message-id: <14819.22098.949421.575504@kwikemart.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan>
X-SW-Source: 2000-10/msg00042.html
Content-length: 1140
Kevin Buettner writes:
> On Oct 10, 11:55am, Daniel Berlin wrote:
>
> > Elena Zannoni <ezannoni@cygnus.com> writes:
> >
> > > BTW, I thought
> > > we agreed to leave the do--while construct in the
> > > SYMBOL_INIT_DEMANGLED_NAME macro.
> > I'd rather not.
> > It's not used in if statements, and *never* should be.
> > The argument that someone, someday, might want to, just isn't
> > convincing, because they shouldn't.
>
> Daniel,
>
> This is really not the way to handle this kind of change. Elena is
> right. The consensus was to leave the ``do ... while (0)'' construct
> in the SYMBOL_INIT_DEMANGLED_NAME macro. I believe that turning it
> into a proper function was also discussed and is regarded as a viable,
> perhaps even superior, alternative.
>
Yes. That is what I remember as well.
See:
http://sources.redhat.com/ml/gdb-patches/2000-08/msg00202.html
Elena
> I know that you don't like the do ... while (0) construct, but it is
> not right for you to try to sneak changes eliminating it past the
> maintainer multiple times, particularly when you agreed to leave it
> in.
>
> Kevin
>
From dberlin@redhat.com Tue Oct 10 11:01:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 11:01:00 -0000
Message-id: <m38zrwa832.fsf@dan2.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan>
X-SW-Source: 2000-10/msg00043.html
Content-length: 3190
Kevin Buettner <kevinb@cygnus.com> writes:
> On Oct 10, 11:55am, Daniel Berlin wrote:
>
> > Elena Zannoni <ezannoni@cygnus.com> writes:
> >
> > > BTW, I thought
> > > we agreed to leave the do--while construct in the
> > > SYMBOL_INIT_DEMANGLED_NAME macro.
> > I'd rather not.
> > It's not used in if statements, and *never* should be.
> > The argument that someone, someday, might want to, just isn't
> > convincing, because they shouldn't.
>
> Daniel,
>
> This is really not the way to handle this kind of change. Elena is
> right. The consensus was to leave the ``do ... while (0)'' construct
> in the SYMBOL_INIT_DEMANGLED_NAME macro.
No, there was no consensus, we only really discussed *why* it existed that
way. Nobody provided a convincing reason to keep it the old way, except "It
was that way".
> I believe that turning it
> into a proper function was also discussed and is regarded as a viable,
> perhaps even superior, alternative.
Feel free to do this.
I'm not playing with symbol tables anymore, I don't have time to wait
for my patches to get approved.
>
> I know that you don't like the do ... while (0) construct, but it is
> not right for you to try to sneak changes eliminating it past the
> maintainer multiple times, particularly when you agreed to leave it
> in.
I haven't tried to sneak it in, the elimination exists in every
repository i've applied any version of the C++ patches to, so i have to hand
patch every single diff I generate to put it back.
It's not like I can just magically make it reappear in all the
repository copies I have around.
The reality is it exists in the one repository that matters in this
case:
#define SYMBOL_INIT_LANGUAGE_SPECIFIC(symbol,language) \
do { \
SYMBOL_LANGUAGE (symbol) = language; \
if (SYMBOL_LANGUAGE (symbol) == language_cplus \
|| SYMBOL_LANGUAGE (symbol) == language_java \
) \
{ \
SYMBOL_CPLUS_DEMANGLED_NAME (symbol) = NULL; \
} \
else if (SYMBOL_LANGUAGE (symbol) == language_chill) \
{ \
SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL; \
} \
else \
{ \
memset (&(symbol)->ginfo.language_specific, 0, \
sizeof ((symbol)->ginfo.language_specific)); \
} \
} while (0)
I really resent the implication.
I split the patches and did modifications based on the existing set of
patches, which is why the patch has it.
>
> Kevin
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH]: C++ mangling patch that is about to be committed
[not found] ` <m38zrwa832.fsf@dan2.cygnus.com>
@ 2000-10-10 11:07 ` Daniel Berlin
0 siblings, 0 replies; 7+ messages in thread
From: Daniel Berlin @ 2000-10-10 11:07 UTC (permalink / raw)
To: Kevin Buettner; +Cc: Elena Zannoni, gdb-patches
Daniel Berlin <dberlin@redhat.com> writes:
> Kevin Buettner <kevinb@cygnus.com> writes:
>
> > On Oct 10, 11:55am, Daniel Berlin wrote:
> >
> > > Elena Zannoni <ezannoni@cygnus.com> writes:
> > >
> > > > BTW, I thought
> > > > we agreed to leave the do--while construct in the
> > > > SYMBOL_INIT_DEMANGLED_NAME macro.
> > > I'd rather not.
> > > It's not used in if statements, and *never* should be.
> > > The argument that someone, someday, might want to, just isn't
> > > convincing, because they shouldn't.
> >
> > Daniel,
> >
> > This is really not the way to handle this kind of change. Elena is
> > right. The consensus was to leave the ``do ... while (0)'' construct
> > in the SYMBOL_INIT_DEMANGLED_NAME macro.
>
> No, there was no consensus, we only really discussed *why* it existed that
> way. Nobody provided a convincing reason to keep it the old way, except "It
> was that way".
>
> > I believe that turning it
> > into a proper function was also discussed and is regarded as a viable,
> > perhaps even superior, alternative.
>
> Feel free to do this.
> I'm not playing with symbol tables anymore, I don't have time to wait
> for my patches to get approved.
>
> >
> > I know that you don't like the do ... while (0) construct, but it is
> > not right for you to try to sneak changes eliminating it past the
> > maintainer multiple times, particularly when you agreed to leave it
> > in.
>
> I haven't tried to sneak it in, the elimination exists in every
> repository i've applied any version of the C++ patches to, so i have to hand
> patch every single diff I generate to put it back.
>
> It's not like I can just magically make it reappear in all the
> repository copies I have around.
>
> The reality is it exists in the one repository that matters in this
> case:
I actually copied/pasted the wrong macro, i meant:
#define SYMBOL_INIT_DEMANGLED_NAME(symbol,obstack) \
do { \
char *demangled = NULL; \
if (SYMBOL_LANGUAGE (symbol) == language_unknown) \
SYMBOL_LANGUAGE(symbol) = language_auto; \
if (SYMBOL_LANGUAGE (symbol) == language_cplus \
|| SYMBOL_LANGUAGE (symbol) == language_auto) \
{ \
demangled = \
cplus_demangle (SYMBOL_NAME (symbol), DMGL_PARAMS | DMGL_ANSI);\
if (demangled != NULL) \
{ \
SYMBOL_LANGUAGE (symbol) = language_cplus; \
SYMBOL_CPLUS_DEMANGLED_NAME (symbol) = \
obsavestring (demangled, strlen (demangled), (obstack)); \
free (demangled); \
} \
else \
{ \
SYMBOL_CPLUS_DEMANGLED_NAME (symbol) = NULL; \
} \
} \
if (SYMBOL_LANGUAGE (symbol) == language_java) \
{ \
demangled = \
cplus_demangle (SYMBOL_NAME (symbol), \
DMGL_PARAMS | DMGL_ANSI | DMGL_JAVA); \
if (demangled != NULL) \
{ \
SYMBOL_LANGUAGE (symbol) = language_java; \
SYMBOL_CPLUS_DEMANGLED_NAME (symbol) = \
obsavestring (demangled, strlen (demangled), (obstack)); \
free (demangled); \
} \
else \
{ \
SYMBOL_CPLUS_DEMANGLED_NAME (symbol) = NULL; \
} \
} \
if (demangled == NULL \
&& (SYMBOL_LANGUAGE (symbol) == language_chill \
|| SYMBOL_LANGUAGE (symbol) == language_auto)) \
{ \
demangled = \
chill_demangle (SYMBOL_NAME (symbol)); \
if (demangled != NULL) \
{ \
SYMBOL_LANGUAGE (symbol) = language_chill; \
SYMBOL_CHILL_DEMANGLED_NAME (symbol) = \
obsavestring (demangled, strlen (demangled), (obstack)); \
free (demangled); \
} \
else \
{ \
SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL; \
} \
} \
} while(0)
As you can see, the do/while is clearly there.
>
> I really resent the implication.
> I split the patches and did modifications based on the existing set of
> patches, which is why the patch has it.
>
> >
> > Kevin
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH]: C++ mangling patch that is about to be committed
[not found] ` <m3k8bgadxp.fsf@dan2.cygnus.com>
2000-10-10 10:38 ` Kevin Buettner
@ 2000-10-10 11:25 ` Michael Snyder
[not found] ` <m3zokc8p3c.fsf@dan2.cygnus.com>
1 sibling, 1 reply; 7+ messages in thread
From: Michael Snyder @ 2000-10-10 11:25 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Elena Zannoni, gdb-patches
Daniel Berlin wrote:
>
> Elena Zannoni <ezannoni@cygnus.com> writes:
>
> > Daniel,
> >
> > There is an extra change in symtab.h that has nothing to do with the
> > changelog. I think that is part of a different patch.
> No, I missed the changelog entry for it, stupidly.
>
> > BTW, I thought
> > we agreed to leave the do--while construct in the
> > SYMBOL_INIT_DEMANGLED_NAME macro.
> I'd rather not.
> It's not used in if statements, and *never* should be.
> The argument that someone, someday, might want to, just isn't
> convincing, because they shouldn't.
Umm... Daniel, did you and Elena discuss it?
Overriding her opinion by taking it out of a file
that she maintains and creating a new one that you
maintain does NOT seem to be in the spirit of
maintainership...
From msnyder@redhat.com Tue Oct 10 11:36:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Kevin Buettner <kevinb@cygnus.com>, Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 11:36:00 -0000
Message-id: <39E361AD.563F@redhat.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> <m38zrwa832.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00046.html
Content-length: 3675
Daniel Berlin wrote:
>
> Kevin Buettner <kevinb@cygnus.com> writes:
>
> > On Oct 10, 11:55am, Daniel Berlin wrote:
> >
> > > Elena Zannoni <ezannoni@cygnus.com> writes:
> > >
> > > > BTW, I thought
> > > > we agreed to leave the do--while construct in the
> > > > SYMBOL_INIT_DEMANGLED_NAME macro.
> > > I'd rather not.
> > > It's not used in if statements, and *never* should be.
> > > The argument that someone, someday, might want to, just isn't
> > > convincing, because they shouldn't.
> >
> > Daniel,
> >
> > This is really not the way to handle this kind of change. Elena is
> > right. The consensus was to leave the ``do ... while (0)'' construct
> > in the SYMBOL_INIT_DEMANGLED_NAME macro.
>
> No, there was no consensus, we only really discussed *why* it existed that
> way. Nobody provided a convincing reason to keep it the old way, except "It
> was that way".
If it was discussed and there was no consensus, then
the DEFAULT action should be "no change". Especially
if the maintainer responsible for that file did not
approve the change.
> > I believe that turning it
> > into a proper function was also discussed and is regarded as a viable,
> > perhaps even superior, alternative.
>
> Feel free to do this.
> I'm not playing with symbol tables anymore, I don't have time to wait
> for my patches to get approved.
I'm sorry you feel that way. Waiting for patches to be approved
is part of the consensus that must exist, to work on a group
project. I hope you can get used to it.
> > I know that you don't like the do ... while (0) construct, but it is
> > not right for you to try to sneak changes eliminating it past the
> > maintainer multiple times, particularly when you agreed to leave it
> > in.
>
> I haven't tried to sneak it in, the elimination exists in every
> repository i've applied any version of the C++ patches to, so i have to hand
> patch every single diff I generate to put it back.
>
> It's not like I can just magically make it reappear in all the
> repository copies I have around.
>
> The reality is it exists in the one repository that matters in this
> case:
> #define SYMBOL_INIT_LANGUAGE_SPECIFIC(symbol,language) \
> do { \
> SYMBOL_LANGUAGE (symbol) = language; \
> if (SYMBOL_LANGUAGE (symbol) == language_cplus \
> || SYMBOL_LANGUAGE (symbol) == language_java \
> ) \
> { \
> SYMBOL_CPLUS_DEMANGLED_NAME (symbol) = NULL; \
> } \
> else if (SYMBOL_LANGUAGE (symbol) == language_chill) \
> { \
> SYMBOL_CHILL_DEMANGLED_NAME (symbol) = NULL; \
> } \
> else \
> { \
> memset (&(symbol)->ginfo.language_specific, 0, \
> sizeof ((symbol)->ginfo.language_specific)); \
> } \
> } while (0)
>
>
> I really resent the implication.
> I split the patches and did modifications based on the existing set of
> patches, which is why the patch has it.
>
> >
> > Kevin
From ac131313@cygnus.com Tue Oct 10 12:09:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: [maint] add FNF to write after approval list
Date: Tue, 10 Oct 2000 12:09:00 -0000
Message-id: <39E1EB29.415C3059@cygnus.com>
X-SW-Source: 2000-10/msg00047.html
Content-length: 60
Just FYI,
I see no reason for this to not occure.
Andrew
From dberlin@redhat.com Tue Oct 10 12:37:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Michael Snyder <msnyder@redhat.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 12:37:00 -0000
Message-id: <m3zokc8p3c.fsf@dan2.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <39E35F1D.6070@redhat.com>
X-SW-Source: 2000-10/msg00048.html
Content-length: 2234
Michael Snyder <msnyder@redhat.com> writes:
> Daniel Berlin wrote:
> >
> > Elena Zannoni <ezannoni@cygnus.com> writes:
> >
> > > Daniel,
> > >
> > > There is an extra change in symtab.h that has nothing to do with the
> > > changelog. I think that is part of a different patch.
> > No, I missed the changelog entry for it, stupidly.
> >
> > > BTW, I thought
> > > we agreed to leave the do--while construct in the
> > > SYMBOL_INIT_DEMANGLED_NAME macro.
> > I'd rather not.
> > It's not used in if statements, and *never* should be.
> > The argument that someone, someday, might want to, just isn't
> > convincing, because they shouldn't.
>
> Umm... Daniel, did you and Elena discuss it?
Elena didn't participate in that discussion, it was held on
gdb-patches in clear view.
> Overriding her opinion by taking it out of a file
> that she maintains and creating a new one that you
> maintain does NOT seem to be in the spirit of
> maintainership...
Err, i'm not.
It's always been in symtab.h
I don't plan on moving that macro to cp-support.h,.
What made you think it was being taken out of a file she maintains,
and moved to one i maintain.
Elena is the backup maintainer.
THat's part of the whole problem.
The maintainer hasn't participated in maintaining the file in a while.
Like I said, since this stuff isn't in my maintainership, i'm not
fixing it anymore.
Someone else can fix it, whether it affects C++ support or not.
That is what part of being a maintainer is, right? Maintaining?
It's interesting that you seem to be bashing my plan to move the C++
support specific things to cp-support.c, out of places they don't
belong (this is what i'm assuming you think i'm doing when you say
moving things out of a file someone else maintains, and into one i
maintain), since nobody maintains them but me, because they are C++ specific.
I'm expected to look at problems related to them, and fix them, rather
than the person whose maintainership they do fall under, yet I have
to get the patches approved by other people, since i'm not supposed to
maintain them. So i'm to maintain them, but not maintain them. Weird.
Nobody else has fixed this stuff in years, so it's not a matter of me
just getting to it first.
--Dan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH]: C++ mangling patch that is about to be committed
[not found] ` <m3zokc8p3c.fsf@dan2.cygnus.com>
@ 2000-10-10 16:12 ` Elena Zannoni
2000-10-10 17:33 ` Daniel Berlin
0 siblings, 1 reply; 7+ messages in thread
From: Elena Zannoni @ 2000-10-10 16:12 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Michael Snyder, Elena Zannoni, gdb-patches
Daniel Berlin writes:
> Michael Snyder <msnyder@redhat.com> writes:
>
> > Daniel Berlin wrote:
> > >
> > > Elena Zannoni <ezannoni@cygnus.com> writes:
> > >
> > > > Daniel,
> > > >
> > > > There is an extra change in symtab.h that has nothing to do with the
> > > > changelog. I think that is part of a different patch.
> > > No, I missed the changelog entry for it, stupidly.
> > >
> > > > BTW, I thought
> > > > we agreed to leave the do--while construct in the
> > > > SYMBOL_INIT_DEMANGLED_NAME macro.
> > > I'd rather not.
> > > It's not used in if statements, and *never* should be.
> > > The argument that someone, someday, might want to, just isn't
> > > convincing, because they shouldn't.
> >
> > Umm... Daniel, did you and Elena discuss it?
>
> Elena didn't participate in that discussion, it was held on
> gdb-patches in clear view.
>
And the consensus was that the do--while would stay or the macro would
be changed to a function. So, let's just leave the do--while, and
make the c++ changes you propose to the macro. No need to make it a
function this time around.
> > Overriding her opinion by taking it out of a file
> > that she maintains and creating a new one that you
> > maintain does NOT seem to be in the spirit of
> > maintainership...
> Err, i'm not.
> It's always been in symtab.h
> I don't plan on moving that macro to cp-support.h,.
> What made you think it was being taken out of a file she maintains,
> and moved to one i maintain.
> Elena is the backup maintainer.
> THat's part of the whole problem.
> The maintainer hasn't participated in maintaining the file in a while.
> Like I said, since this stuff isn't in my maintainership, i'm not
> fixing it anymore.
> Someone else can fix it, whether it affects C++ support or not.
> That is what part of being a maintainer is, right? Maintaining?
>
You don't have to fix it. It can stay as it is now.
> It's interesting that you seem to be bashing my plan to move the C++
> support specific things to cp-support.c, out of places they don't
> belong (this is what i'm assuming you think i'm doing when you say
> moving things out of a file someone else maintains, and into one i
> maintain), since nobody maintains them but me, because they are C++ specific.
>
> I'm expected to look at problems related to them, and fix them, rather
> than the person whose maintainership they do fall under, yet I have
> to get the patches approved by other people, since i'm not supposed to
> maintain them. So i'm to maintain them, but not maintain them. Weird.
> Nobody else has fixed this stuff in years, so it's not a matter of me
> just getting to it first.
>
>
Maybe not everybody feels like I do about this, but I believe that
peer review is important. Whether or not I am the maintainer for
something, I always like to post my patches and have other people look
at them. Yes, sometimes it may take a while, because of lack of
coordination among the maintainers, or because the maintainers are
busy, but I think it is very worthwhile.
Unfortunately sometimes there isn't a clear demarcation between areas
of maintainership, often there is overlap. Nothing wrong with
that. Two pairs of eyes should probably do a better job, I would
think.
About moving the c++ stuff out of the symtab related files. Dan, post
your proposed changes when you are ready, and then we can talk more.
Do you think it would be a good idea to have a C++ co/backup
maintainer, if this would make your life easier?
> --Dan
>
>
Elena
From kevinb@cygnus.com Tue Oct 10 16:16:00 2000
From: Kevin Buettner <kevinb@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 16:16:00 -0000
Message-id: <1001010231608.ZM2722@ocotillo.lan>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> <m38zrwa832.fsf@dan2.cygnus.com> <dberlin@redhat.com>
X-SW-Source: 2000-10/msg00050.html
Content-length: 476
On Oct 10, 2:01pm, Daniel Berlin wrote:
> I really resent the implication.
> I split the patches and did modifications based on the existing set of
> patches, which is why the patch has it.
My apologies then. But I suggest you be more careful about what you
send to the list in the future. It is rather disconcerting to warn
you about a problem (which you say you've fixed in your version of the
sources) only to see it show up in later patches again (and again).
Kevin
From dberlin@redhat.com Tue Oct 10 17:16:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: C++ mangling patch that is about to be committed
Date: Tue, 10 Oct 2000 17:16:00 -0000
Message-id: <m3g0m46xm4.fsf@dan2.cygnus.com>
References: <m38zrw4w2p.fsf@dan2.cygnus.com> <14819.13803.331153.108644@kwikemart.cygnus.com> <m3k8bgadxp.fsf@dan2.cygnus.com> <1001010173833.ZM2250@ocotillo.lan> <m38zrwa832.fsf@dan2.cygnus.com> <1001010231608.ZM2722@ocotillo.lan>
X-SW-Source: 2000-10/msg00051.html
Content-length: 936
Kevin Buettner <kevinb@cygnus.com> writes:
> On Oct 10, 2:01pm, Daniel Berlin wrote:
>
> > I really resent the implication.
> > I split the patches and did modifications based on the existing set of
> > patches, which is why the patch has it.
>
> My apologies then. But I suggest you be more careful about what you
> send to the list in the future. It is rather disconcerting to warn
> you about a problem (which you say you've fixed in your version of the
> sources) only to see it show up in later patches again (and again).
>
> Kevin
Yes, I'll try. It's mainly because I have so many changes to those
files that it's easier to just modify the original patches by hand
than try to rediff.
I haven't rediffed this stuff since I originally sent it.
Which is why it keeps showing up.
I actually have to checkout the repository into a new directory just
to commit this set of patches, so i don't get the other changes.
--Dan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH]: C++ mangling patch that is about to be committed
2000-10-10 16:12 ` Elena Zannoni
@ 2000-10-10 17:33 ` Daniel Berlin
0 siblings, 0 replies; 7+ messages in thread
From: Daniel Berlin @ 2000-10-10 17:33 UTC (permalink / raw)
To: Elena Zannoni; +Cc: Michael Snyder, gdb-patches, cgf
>
> And the consensus was that the do--while would stay or the macro would
> be changed to a function. So, let's just leave the do--while, and
> make the c++ changes you propose to the macro. No need to make it a
> function this time around.
Elena, are you officially symtab maintainer until such time as jim
blandy comes back to this dimension?
Can we note this in the maintainers, so i don't bug the wrong people?
>
> > Err, i'm not.
> > It's always been in symtab.h
> > I don't plan on moving that macro to cp-support.h,.
> > What made you think it was being taken out of a file she maintains,
> > and moved to one i maintain.
> > Elena is the backup maintainer.
> > THat's part of the whole problem.
> > The maintainer hasn't participated in maintaining the file in a while.
> > Like I said, since this stuff isn't in my maintainership, i'm not
> > fixing it anymore.
> > Someone else can fix it, whether it affects C++ support or not.
> > That is what part of being a maintainer is, right? Maintaining?
> >
>
> You don't have to fix it. It can stay as it is now.
>
This was what happened for many years.
What i haven't changed in C++ support hasn't changed since it was
written for g++ 2.6.4.
Some of the comments probably still mention "this being broken in
2.6.4", IIRC.
I took over C++ maintainership mainly because I couldn't stand dealing
with trying to debug C++ with gdb, because it was worthless.
> >
> Maybe not everybody feels like I do about this, but I believe that
> peer review is important. Whether or not I am the maintainer for
> something, I always like to post my patches and have other people look
> at them. Yes, sometimes it may take a while, because of lack of
> coordination among the maintainers, or because the maintainers are
> busy, but I think it is very worthwhile.
Let me give you an example of what's going to happen in a few months.
The new-abi for C++ will be turned on in gcc.
At this time, all C++ support in gdb will break.
There is nothing I can do about this, the new-abi is still not tested
enough that I can make it work in GDB yet without it breaking two days
later.
Literally every single C++ test will start failing.
How long it takes me to make it work again directly will depend on how
long it takes to get approvals.
If all the C++ support stuff is moved into cp-support.c, i'll only
need to post the patches, see if anyone sees anything blatantly wrong,
and then commit it.
Otherwise, going by the filenames, it'll cross about 8 or 9 files,
meaning i have to get approval from maintainers of language support,
symtab support, etc, when most of the routines i'm changing actually
have nothing to do with any of that stuff.
I'm not doing this to avoid getting approvals, but to avoid wasting
other maintainers time having to look at stuff that isn't anywhere
near their area of expertise. I'm happy to get approval for changes
that really are symbol table changes, or dwarf2 reader changes. But
what i'm trying to move into cp-support.c isn't.
gdb_mangle_name is a perfect example.
It has nothing to do with symbols.
All it does is take a type structure, a method id, and a signature,
and build a new mangled name for it.
It involves magical knowledge of how g++ mangles names.
It doesn't even have a struct symbol in it, or anywhere near it.
It isn't called except from a few C++ specific routines (cp-valprint
or typeprint calls it, and one other place that escapes the mind).
Of course, it's in symtab.c.
Are you starting to see my point?
The people i have to get approval for are really not qualified to
examine the patches.
No offense, but taking you as an example, it took you a while to
figure out what my changes were doing, and they aren't obsfuscated
code.
>
> Unfortunately sometimes there isn't a clear demarcation between areas
> of maintainership, often there is overlap. Nothing wrong with
> that. Two pairs of eyes should probably do a better job, I would
> think.
However, sometimes, it's just a pain in the ass.
>
> About moving the c++ stuff out of the symtab related files. Dan, post
> your proposed changes when you are ready, and then we can talk more.
I have to, because it affects about 8 different files, and will
require so many approvals it's not even funny.
It's funny. This stuff has actually been moved before.
gdb_mangle_name's declaration is in gdbtypes.h, yet it's definition is
in symtab.c
etc.
> Do you think it would be a good idea to have a C++ co/backup
> maintainer, if this would make your life easier?
Yes, it would make my life easier, but I doubt we have that many
massochists around.
>
> > --Dan
> >
> >
>
> Elena
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2000-10-10 17:33 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-10-10 7:20 [PATCH]: C++ mangling patch that is about to be committed Daniel Berlin
2000-10-10 8:29 ` Elena Zannoni
[not found] ` <m3k8bgadxp.fsf@dan2.cygnus.com>
2000-10-10 10:38 ` Kevin Buettner
[not found] ` <m38zrwa832.fsf@dan2.cygnus.com>
2000-10-10 11:07 ` Daniel Berlin
2000-10-10 11:25 ` Michael Snyder
[not found] ` <m3zokc8p3c.fsf@dan2.cygnus.com>
2000-10-10 16:12 ` Elena Zannoni
2000-10-10 17:33 ` Daniel Berlin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox