Re: [PATCH]: C++ mangling patch that is about to be committed

[Daniel Berlin <dberlin at redhat dot com>]

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