* Re: Rewriting the type system
2001-06-11 11:43 ` Rewriting the type system Daniel Berlin
@ 2001-06-11 16:58 ` Stan Shebs
2001-06-12 1:44 ` Eli Zaretskii
` (2 subsequent siblings)
3 siblings, 0 replies; 21+ messages in thread
From: Stan Shebs @ 2001-06-11 16:58 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Jim Blandy, gdb-patches
Daniel Berlin wrote:
>
> Jim Blandy <jimb@zwingli.cygnus.com> writes:
>
> > By making
> > sure the fundamental design of your change meets their requirements
> > *before* you invest the time to turn your ideas into a patch, you may
> > avoid having to rewrite the change from scratch.
>
> Not a problem. By the time the patch gets reviewed, it'll be rewritten anyway.
> Even the very simple patch to add the misc obstack to the objfiles,
> and stop putting things in the psymbol obstack that don't belong, from
> May 29th, hasn't been reviewed yet.
That's two weeks, which is a little long but not unreasonable.
> Hell, the simple bcache change i submitted last year (updating the
> starting constant, fix the indenting) still hasn't
> been reviewed.
That is an unreasonable delay. As you know from GCC land, the usual
thing there is to post an "Unreviewed patches" messages with xrefs to
the original patch submissions.
> Jim, GDB development is moving a lot slower than it should. If
> someone told me, after just rewriting the typesystem, that i needed to
> redo it from scratch, i'd probably just start making my own GDB
> releases instead (in effect, forking GDB). Not out of spite or
> anything, just so i could get stuff done without having to keep track
> of tons of patches that go months without review.
Certainly that is your right according to the GPL, and perhaps even
your duty if GDB maintainers are not doing the job. However, before
you go that far, I'd at least like to get the official flame that
you have patches X, Y, Z, etc, that have been sitting ignored.
I need the URLs so I can see the followups - perhaps they've been
discussed, but the review proper was poor or incomplete. Also,
I remember seeing remarks, including some by yourself, to the effect
that some of your patches were incomplete in various ways. As
someone who's complained about, say, problem code from HP, I'm
sure you'll appreciate the reluctance to take in code which the
author admits has problems. (I may be mis-remembering - another
reason for pointers to specific messages.)
I admire the energy that you're bringing to GDB development, but
please have some patience. The review process is our way of keeping
everything working, and because I've been involved with GDB for a
long time and bear a measure of responsibility for its current
state, many times in the past couple of years I've had to watch
somebody struggle with some piece of code, and know that it was
because years earlier it was easy or expedient just to allow it in,
instead of demanding something better. Not a good feeling,
especially when it's clear that the struggling is consuming time
that could have been used on new development instead.
Stan
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Rewriting the type system
2001-06-11 11:43 ` Rewriting the type system Daniel Berlin
2001-06-11 16:58 ` Stan Shebs
@ 2001-06-12 1:44 ` Eli Zaretskii
2001-06-12 9:12 ` Daniel Berlin
2001-06-12 10:16 ` Jim Blandy
2001-06-12 14:03 ` Andrew Cagney
3 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2001-06-12 1:44 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Jim Blandy, gdb-patches
On 11 Jun 2001, Daniel Berlin wrote:
> Even the very simple patch to add the misc obstack to the objfiles,
> and stop putting things in the psymbol obstack that don't belong, from
> May 29th, hasn't been reviewed yet.
> Hell, the simple bcache change i submitted last year (updating the
> starting constant, fix the indenting) still hasn't
> been reviewed.
>
> Jim, GDB development is moving a lot slower than it should.
My experience is very different. Every change that I suggested until
now, for the past 2 years or so that I'm involved with GDB
maintenance, was usually reviewed within 1-2 weeks of my posting it
as an RFA. A few times I needed to post a reminder (I usually do that
after more than a week's passed without any replies). A couple of
times, I needed more than one reminder, but that's an exception rather
than the rule, in my experience.
In most cases, I had my patches reviewed and approved in 2-3 weeks,
sometimes a month. In one exceptional case, it took 3 or 4 months,
but that was my first large submission, and I failed to ping the
relevant maintainer more than once.
So GDB development is not slow, in my opinion. More importantly, I'm
always able to get my patches accepted by using the normal channels,
such as pinging people from time to time.
In other words, the development procedures work.
> If someone told me, after just rewriting the typesystem, that i
> needed to redo it from scratch, i'd probably just start making my
> own GDB releases instead (in effect, forking GDB).
As I already wrote elsewhere, if you care about GDB, please stop
talking about a fork, because even talking about it can do a
tremendous damage to the nice cooperative development atmosphere we
have in GDB. I've been and am involved in quite a few other free
software packages, and I'm telling you that GDB is one of the nicest,
most cooperative environments I had ever experienced. Please, let's
cherish that!
While there's always place for improvement, let's suggest such
improvements in a constructive way, and let's assume that everybody in
this fine forum has the same goal: making GDB better. Offending
people by talking about a fork is not a good way, to say the least, of
asking them to be more responsive to your submissions. It _is_,
however, an efficient way of making cooperation harder.
(I'm sorry about lecturing, but I cannot in good faith look the other
way when people talk about forking.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rewriting the type system
2001-06-12 1:44 ` Eli Zaretskii
@ 2001-06-12 9:12 ` Daniel Berlin
2001-06-12 10:01 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Daniel Berlin @ 2001-06-12 9:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Daniel Berlin, Jim Blandy, gdb-patches
Eli Zaretskii <eliz@is.elta.co.il> writes:
> On 11 Jun 2001, Daniel Berlin wrote:
>
>> Even the very simple patch to add the misc obstack to the objfiles,
>> and stop putting things in the psymbol obstack that don't belong, from
>> May 29th, hasn't been reviewed yet.
>> Hell, the simple bcache change i submitted last year (updating the
>> starting constant, fix the indenting) still hasn't
>> been reviewed.
>>
>> Jim, GDB development is moving a lot slower than it should.
>
> My experience is very different. Every change that I suggested until
> now, for the past 2 years or so that I'm involved with GDB
> maintenance, was usually reviewed within 1-2 weeks of my posting it
> as an RFA. A few times I needed to post a reminder (I usually do that
> after more than a week's passed without any replies). A couple of
> times, I needed more than one reminder, but that's an exception rather
> than the rule, in my experience.
This is because you work on different parts of GDB then I do.
As I just pointed out to Stan, i'm not alone. I received 4 replies to the
message I posted saying "I know exactly how you feel" or "Your not
kidding". These are people who no longer contribute to GDB, saying
they are waiting for a time when they can get, for instance, a simple
Makefile.in patch, reviewed within 3 months.
That's sad.
>
> In most cases, I had my patches reviewed and approved in 2-3 weeks,
> sometimes a month. In one exceptional case, it took 3 or 4 months,
> but that was my first large submission, and I failed to ping the
> relevant maintainer more than once.
>
> So GDB development is not slow, in my opinion. More importantly, I'm
> always able to get my patches accepted by using the normal channels,
> such as pinging people from time to time.
>
> In other words, the development procedures work.
Maybe for your area of GDB.
Not for mine.
And apparently, not for some others.
Do you really think i'd complain if I was alone here?
If I thought it was just me?
--
"The other day, I was walking my dog around my building... on
the ledge. Some people are afraid of heights. Not me, I'm
afraid of widths.
"-Steven Wright
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rewriting the type system
2001-06-12 9:12 ` Daniel Berlin
@ 2001-06-12 10:01 ` Eli Zaretskii
0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2001-06-12 10:01 UTC (permalink / raw)
To: dan; +Cc: jimb, gdb-patches
> From: Daniel Berlin <dan@cgsoftware.com>
> Date: 12 Jun 2001 12:12:49 -0400
>
> > In other words, the development procedures work.
> Maybe for your area of GDB.
> Not for mine.
> And apparently, not for some others.
It's possible that some maintainers are less responsive than others,
and that I had luck talking to one kind while you to the other. By
posting my experience I didn't mean to say that you made up this
stuff. I just wanted to put things into a proper perspective.
> Do you really think i'd complain if I was alone here?
I don't think it's wrong to complain about slow response. _How_ you
complain is important, however.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rewriting the type system
2001-06-11 11:43 ` Rewriting the type system Daniel Berlin
2001-06-11 16:58 ` Stan Shebs
2001-06-12 1:44 ` Eli Zaretskii
@ 2001-06-12 10:16 ` Jim Blandy
2001-06-12 10:44 ` Daniel Berlin
2001-06-12 11:08 ` Daniel Berlin
2001-06-12 14:03 ` Andrew Cagney
3 siblings, 2 replies; 21+ messages in thread
From: Jim Blandy @ 2001-06-12 10:16 UTC (permalink / raw)
To: Daniel Berlin; +Cc: gdb-patches
Daniel Berlin <dan@cgsoftware.com> writes:
> Jim, GDB development is moving a lot slower than it should. If
> someone told me, after just rewriting the typesystem, that i needed to
> redo it from scratch, i'd probably just start making my own GDB
> releases instead (in effect, forking GDB). Not out of spite or
> anything, just so i could get stuff done without having to keep track
> of tons of patches that go months without review.
I apologize if I have been slow to review patches from time to time.
I don't like to feel that I'm a bottleneck in GDB development.
However, in your case, Dan, I think we can back up and ask a more
fundamental question. You're a smart guy; you've got a lot of energy;
you have a lot of time, too, apparently. You've been working on GDB
for at least a year and a half now. You've taken on large, ambitious
tasks.
So, given all that, why are you in the position of waiting for my
approval for your changes? Why aren't you listed as a maintainer of
the Dwarf2 reader and the symtab reader?
It's because, for whatever reason, you don't take the time to make
your changes correct.
Here is part of the function gnuv3_rtti_type in gnu-v3-abi.c, from
your GCC V3 C++ ABI support patch:
coreptr =
*((CORE_ADDR *) (VALUE_CONTENTS_ALL (v) + VALUE_OFFSET (v) +
VALUE_EMBEDDED_OFFSET (v)));
coreptr -= 12;
*top =
value_as_long (value_at
(builtin_type_int, coreptr, VALUE_BFD_SECTION (v)));
coreptr += 8;
vp = value_at (builtin_type_int, coreptr, VALUE_BFD_SECTION (v));
Here we have, in the space of less than a dozen lines of code:
- host == target assumptions (why are you applying `*' to
target-format data?)
- sizeof (foo) assumptions (what is 8? what is 12?)
It makes me angry to be asked to review this kind of patch. If you're
not going to bother with even the most basic rules of GDB development,
why should I bother to read your patches?
You have an extensive history of reverted changes:
2000-11-07 Daniel Berlin <dberlin@redhat.com>
* dwarf2read.c: Revert June 5th change for caching of types,
as per Jim Blandy's request.
and the changes to lookup_symbol that were broken, the minsym sorting
issue that Peter Schauer called you on, etc.
One of the reasons it took me three or four months to review your GCC
V3 C++ ABI changes was that I had to learn enough C++ to be able to
understand the ABI spec. Isn't that odd? Why do we need to have our
C++ maintainer's patches reviewed by someone who doesn't know the
language? As someone said recently, "This, IMHO, is amazingly silly."
Given your record, I'm not sure I think you should be the GDB C++
maintainer, or the maintainer of any part of GDB.
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Rewriting the type system
2001-06-12 10:16 ` Jim Blandy
@ 2001-06-12 10:44 ` Daniel Berlin
2001-06-12 14:02 ` Stan Shebs
2001-06-12 11:08 ` Daniel Berlin
1 sibling, 1 reply; 21+ messages in thread
From: Daniel Berlin @ 2001-06-12 10:44 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Berlin, gdb-patches
Jim Blandy <jimb@zwingli.cygnus.com> writes:
> Daniel Berlin <dan@cgsoftware.com> writes:
>> Jim, GDB development is moving a lot slower than it should. If
>> someone told me, after just rewriting the typesystem, that i needed to
>> redo it from scratch, i'd probably just start making my own GDB
>> releases instead (in effect, forking GDB). Not out of spite or
>> anything, just so i could get stuff done without having to keep track
>> of tons of patches that go months without review.
>
> I apologize if I have been slow to review patches from time to time.
> I don't like to feel that I'm a bottleneck in GDB development.
>
> However, in your case, Dan, I think we can back up and ask a more
> fundamental question. You're a smart guy; you've got a lot of energy;
> you have a lot of time, too, apparently. You've been working on GDB
> for at least a year and a half now. You've taken on large, ambitious
> tasks.
>
> So, given all that, why are you in the position of waiting for my
> approval for your changes? Why aren't you listed as a maintainer of
> the Dwarf2 reader and the symtab reader?
>
> It's because, for whatever reason, you don't take the time to make
> your changes correct.
Now that's simply bullshit.
>
> Here is part of the function gnuv3_rtti_type in gnu-v3-abi.c, from
> your GCC V3 C++ ABI support patch:
>
> coreptr =
> *((CORE_ADDR *) (VALUE_CONTENTS_ALL (v) + VALUE_OFFSET (v) +
> VALUE_EMBEDDED_OFFSET (v)));
> coreptr -= 12;
> *top =
> value_as_long (value_at
> (builtin_type_int, coreptr, VALUE_BFD_SECTION (v)));
> coreptr += 8;
> vp = value_at (builtin_type_int, coreptr, VALUE_BFD_SECTION (v));
>
> Here we have, in the space of less than a dozen lines of code:
>
> - host == target assumptions (why are you applying `*' to
> target-format data?)
>
> - sizeof (foo) assumptions (what is 8? what is 12?)
>
Neat, but that code was written 2 years ago, when i was first starting
gdb development.
It was introduced into value_rtti_type, and copied in the gnuv3 rtti
type because gnuv3-abi.c was based on gnuv2-abi.c, which was based on
all that code.
> It makes me angry to be asked to review this kind of patch. If you're
> not going to bother with even the most basic rules of GDB
> development,
Really?
That's pretty frickin funny.
Please point out the problems with the misc_obstack changes I
submitted 2 weeks ago, unreviewed.
> why should I bother to read your patches?
Because as maintainer, it's your job?
>
> You have an extensive history of reverted changes:
>
> 2000-11-07 Daniel Berlin <dberlin@redhat.com>
>
> * dwarf2read.c: Revert June 5th change for caching of types,
> as per Jim Blandy's request.
>
> and the changes to lookup_symbol that were broken,
Actually, Jim, they changes to lookup_symbol were broken because of
two things. First, an undocumented change 4 years ago (IE nobody
updated the comments) that caused demangled names to not appear on
partial symbols, only full symbols and minimal symbols.
I submitted a patch to fix the problem by documenting the behavior,
and reverting the binary search on partial symbols, which took until
Jim Ingham noticed the same damn problem 3 months later, and raised
more hell, for you to actually review the damn patch and approve it.
Remember that part?
> the minsym sorting
> issue that Peter Schauer called you on,
What are you talking about?
> etc.
Cute.
Extensive history through 1 example.
>
> One of the reasons it took me three or four months to review your GCC
> V3 C++ ABI changes was that I had to learn enough C++ to be able to
> understand the ABI spec. Isn't that odd? Why do we need to have our
> C++ maintainer's patches reviewed by someone who doesn't know the
> language?
Because they touch the symbol code?
Or the types code?
Or the values code?
Because language support in GDB is hopelessly intertwined with other
parts of GDB, such that you can't fix one thing without touching 18
other parts?
It's nice of you to try to imply that most of my patches are wrong, when they
aren't.
> As someone said recently, "This, IMHO, is amazingly silly."
Hey, maybe I should start taking your quotes out of context too.
>
> Given your record, I'm not sure I think you should be the GDB C++
> maintainer, or the maintainer of any part of GDB.
Okay Jim, you want it, you got it.
I officially give up as C++ maintainer.
I've removed myself from the MAINTAINERS list.
Have fun.
Doesn't change anything, does it?
Don't review my patches, or the patches of others, and i'll complain.
--
"My friend Winnie is a procrastinator. He didn't get his
birthmark until he was eight years old.
"-Steven Wright
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rewriting the type system
2001-06-12 10:44 ` Daniel Berlin
@ 2001-06-12 14:02 ` Stan Shebs
2001-06-13 1:45 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Stan Shebs @ 2001-06-12 14:02 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Jim Blandy, gdb-patches
Daniel Berlin wrote:
>
> Jim Blandy <jimb@zwingli.cygnus.com> writes:
>
> > It's because, for whatever reason, you don't take the time to make
> > your changes correct.
>
> Now that's simply bullshit.
OK OK. For openers, let's agree not to do personal accusations and
profanity on the list. Flame each other in private please, it will
feel just as good and not waste everybody else's time.
> > Here we have, in the space of less than a dozen lines of code:
> >
> > - host == target assumptions (why are you applying `*' to
> > target-format data?)
> >
> > - sizeof (foo) assumptions (what is 8? what is 12?)
>
> Neat, but that code was written 2 years ago, when i was first starting
> gdb development.
> It was introduced into value_rtti_type, and copied in the gnuv3 rtti
> type because gnuv3-abi.c was based on gnuv2-abi.c, which was based on
> all that code.
Dan, if it's mistaken, it's mistaken; excuses and history aren't really
that interesting. We all have things we're not that proud of, myself
probably more than anybody. Let's fix them and go on to the next thing.
> > why should I bother to read your patches?
>
> Because as maintainer, it's your job?
You're right here, Dan. Everybody here talks about maintenance as
if it's some kind of signal honor, but no, it's just a responsibility,
like peer-reviewing scientific papers. You don't get to read the
title and say "Oh, Dr. Luser again, straight to the trash it goes."
Gotta read the whole thing and provide meaningful feedback, and
worse, you're expected to do it within a certain time period. The
worse the patch, the more work it will be to review.
> > You have an extensive history of reverted changes:
Jim, everybody who's worked extensively on GCC or GDB has a history
of reverted changes. It we waited until we were sure that each change
was perfect, progress would be appallingly slow. Every day the GCC
mainline gets patches that raise the hairs on the back of my neck,
and I don't relax until I've confirm they don't break the target for
which I'm responsible. Some of the patches do break GCC; the patch
gets fixed or reverted, and everybody moves on.
> [...on and on...]
> It's nice of you to try to imply that most of my patches are wrong, when they
> aren't.
Both of you are in the wrong here. Jim, you know as well as anyone
that the C++ symbol handling parts of GDB are not so neatly partitioned
that you can review symbol patches without knowing more than a bit about
C++, and Dan, you should be able to admit mistakes in your patches, fix
them and resubmit, rather than flaming the reviewer of the patch.
There is plenty of room to criticize both maintainer responsiveness
and patch quality without turning it into a spitting match, and I'm
disappointed to see the development process sink to this level.
Stan
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rewriting the type system
2001-06-12 14:02 ` Stan Shebs
@ 2001-06-13 1:45 ` Eli Zaretskii
0 siblings, 0 replies; 21+ messages in thread
From: Eli Zaretskii @ 2001-06-13 1:45 UTC (permalink / raw)
To: shebs; +Cc: dan, jimb, gdb-patches
> Date: Tue, 12 Jun 2001 13:50:16 -0700
> From: Stan Shebs <shebs@apple.com>
>
> Both of you are in the wrong here. Jim, you know as well as anyone
> that the C++ symbol handling parts of GDB are not so neatly partitioned
> that you can review symbol patches without knowing more than a bit about
> C++, and Dan, you should be able to admit mistakes in your patches, fix
> them and resubmit, rather than flaming the reviewer of the patch.
>
> There is plenty of room to criticize both maintainer responsiveness
> and patch quality without turning it into a spitting match, and I'm
> disappointed to see the development process sink to this level.
I agree 110%.
Exchanging accusations will get us nowehere; and if Dan feels his
patches are consistently ignored, then something is not right in the
process of reviewing those patches and providing relevant feedback
back to Dan.
In particular, if there are aspects in Dan's (or anybody else's) code
that the maintainer wants changed, then those aspects should be
pointed out. I know I had such comments on my submissions from time
to time, and I'm sure everyone else had as well.
But leaving patches unreviwed or the person who submitted them in an
uncertain state is something that I think should be avoided at all
costs.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rewriting the type system
2001-06-12 10:16 ` Jim Blandy
2001-06-12 10:44 ` Daniel Berlin
@ 2001-06-12 11:08 ` Daniel Berlin
1 sibling, 0 replies; 21+ messages in thread
From: Daniel Berlin @ 2001-06-12 11:08 UTC (permalink / raw)
To: Jim Blandy; +Cc: Daniel Berlin, gdb-patches
Jim Blandy <jimb@zwingli.cygnus.com> writes:
I'm also curious Jim, did it make you "angry" to review Jason
Merril's 3 line fix for dbxread.c and dwarfread.c, that he submitted
12-15-2000?
You know, that completely incorrect code that said "If we are
processing gcc compilation, it must be old abi demangling"?
Oh wait, you never reviewed it.
That's right.
Elena did, over a month (1 month, 1 day to be exact) later.
Why is it I can get patches that fix crashing bugs in "set
demangle-style" reviewed in hours, but when i, or others, submit
something in your area, it's like a black hole?
I'm pretty sure you don't want me to start dredging out all the
examples where either you've been plain old non-responsive, or taken
months.
Or code that makes me angry to look at, that you've written.
For fun, let's take our recent friend, find_toplevel_char.
2000-01-27 Jim Blandy <jimb@cygnus.com>
* symtab.c (decode_line_1): Don't let commas that are within
quotes or parenthesis terminate the line spec. Don't use pp when
removing the final double quote of a double-quoted string. Don't
forget to skip the opening double quote. I have no clue whether
this change is correct; probably we've just moved this function
from one buggy place to another buggy place, and never came within
an outhouse whiff of correctness.
(find_toplevel_char): New function.
Funny, doesn't seem to me like you tried to make sure the code was
correct.
In fact, it was your addition that caused the problem.
Like I said, you *really* don't want to start playing that
"correctness" of code game.
Neither of us will win. in fact, nobody would win.
The changelogs show that, for instance, Andrew had his last patch to
dwarf2read.c reverted. 3 years later, of course.
I've had *one* patch reverted.
The changelogs clearly show this.
We've all had about the same number of patches reverted.
So please, stop trying to pretend i'm a special case here, or that
i'm a bad egg, who submits bad patches.
It's simply not true.
--Dan
> Daniel Berlin <dan@cgsoftware.com> writes:
>> Jim, GDB development is moving a lot slower than it should. If
>> someone told me, after just rewriting the typesystem, that i needed to
>> redo it from scratch, i'd probably just start making my own GDB
>> releases instead (in effect, forking GDB). Not out of spite or
>> anything, just so i could get stuff done without having to keep track
>> of tons of patches that go months without review.
>
> I apologize if I have been slow to review patches from time to time.
> I don't like to feel that I'm a bottleneck in GDB development.
>
> However, in your case, Dan, I think we can back up and ask a more
> fundamental question. You're a smart guy; you've got a lot of energy;
> you have a lot of time, too, apparently. You've been working on GDB
> for at least a year and a half now. You've taken on large, ambitious
> tasks.
>
> So, given all that, why are you in the position of waiting for my
> approval for your changes? Why aren't you listed as a maintainer of
> the Dwarf2 reader and the symtab reader?
>
> It's because, for whatever reason, you don't take the time to make
> your changes correct.
>
> Here is part of the function gnuv3_rtti_type in gnu-v3-abi.c, from
> your GCC V3 C++ ABI support patch:
>
> coreptr =
> *((CORE_ADDR *) (VALUE_CONTENTS_ALL (v) + VALUE_OFFSET (v) +
> VALUE_EMBEDDED_OFFSET (v)));
> coreptr -= 12;
> *top =
> value_as_long (value_at
> (builtin_type_int, coreptr, VALUE_BFD_SECTION (v)));
> coreptr += 8;
> vp = value_at (builtin_type_int, coreptr, VALUE_BFD_SECTION (v));
>
> Here we have, in the space of less than a dozen lines of code:
>
> - host == target assumptions (why are you applying `*' to
> target-format data?)
>
> - sizeof (foo) assumptions (what is 8? what is 12?)
>
> It makes me angry to be asked to review this kind of patch. If you're
> not going to bother with even the most basic rules of GDB development,
> why should I bother to read your patches?
>
> You have an extensive history of reverted changes:
>
> 2000-11-07 Daniel Berlin <dberlin@redhat.com>
>
> * dwarf2read.c: Revert June 5th change for caching of types,
> as per Jim Blandy's request.
>
> and the changes to lookup_symbol that were broken, the minsym sorting
> issue that Peter Schauer called you on, etc.
>
> One of the reasons it took me three or four months to review your GCC
> V3 C++ ABI changes was that I had to learn enough C++ to be able to
> understand the ABI spec. Isn't that odd? Why do we need to have our
> C++ maintainer's patches reviewed by someone who doesn't know the
> language? As someone said recently, "This, IMHO, is amazingly silly."
>
> Given your record, I'm not sure I think you should be the GDB C++
> maintainer, or the maintainer of any part of GDB.
--
"I was once arrested for walking in someone else's sleep.
"-Steven Wright
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Rewriting the type system
2001-06-11 11:43 ` Rewriting the type system Daniel Berlin
` (2 preceding siblings ...)
2001-06-12 10:16 ` Jim Blandy
@ 2001-06-12 14:03 ` Andrew Cagney
2001-06-12 21:37 ` Daniel Berlin
3 siblings, 1 reply; 21+ messages in thread
From: Andrew Cagney @ 2001-06-12 14:03 UTC (permalink / raw)
To: Daniel Berlin; +Cc: Jim Blandy, gdb-patches
> Hell, the simple bcache change i submitted last year (updating the
> starting constant, fix the indenting) still hasn't
> been reviewed.
This patch?
I'm suprized you didn't take the initiative here and check it in as an
obvious fix.
Andrew
> Index: bcache.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/bcache.c,v
> retrieving revision 1.4
> diff -c -3 -p -r1.4 bcache.c
> *** bcache.c 2000/06/05 20:49:53 1.4
> --- bcache.c 2000/12/08 05:01:18
> ***************
> *** 28,51 ****
> #include "bcache.h"
> #include "gdb_string.h" /* For memcpy declaration */
>
> ! /* The old hash function was stolen from SDBM. This is what DB 3.0 uses now,
> * and is better than the old one.
> */
> \f
> unsigned long
> hash(void *addr, int length)
> {
> ! const unsigned char *k, *e;
> ! unsigned long h;
> !
> ! k = (const unsigned char *)addr;
> ! e = k+length;
> ! for (h=0; k< e;++k)
> ! {
> ! h *=16777619;
> ! h ^= *k;
> ! }
> ! return (h);
> }
> \f
> /* Growing the bcache's hash table. */
> --- 28,55 ----
> #include "bcache.h"
> #include "gdb_string.h" /* For memcpy declaration */
>
> ! /* The old hash function was stolen from SDBM. This is what DB 3.1 uses now,
> * and is better than the old one.
> + * It's the Foller/Noll/Vo hash code, for those who care.
> */
> + #define FNV0_32_INIT (0) /* To use FNV-0, not recommended */
> + #define FNV1_32_INIT (0x811c9dc5)
> + #define FNV_32_PRIME (0x01000193)
> \f
> unsigned long
> hash(void *addr, int length)
> {
> ! const unsigned char *k, *e;
> ! unsigned long h=FNV1_32_INIT;
> !
> ! k = (const unsigned char *)addr;
> ! e = k+length;
> ! for (; k< e;++k)
> ! {
> ! h *= FNV_32_PRIME;
> ! h ^= *k;
> ! }
> ! return (h);
> }
> \f
> /* Growing the bcache's hash table. */
>
>
>
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: Rewriting the type system
2001-06-12 14:03 ` Andrew Cagney
@ 2001-06-12 21:37 ` Daniel Berlin
0 siblings, 0 replies; 21+ messages in thread
From: Daniel Berlin @ 2001-06-12 21:37 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Daniel Berlin, Jim Blandy, gdb-patches
Andrew Cagney <ac131313@cygnus.com> writes:
>> Hell, the simple bcache change i submitted last year (updating the
>> starting constant, fix the indenting) still hasn't
>> been reviewed.
>
>
> This patch?
Yup.
>
> I'm suprized you didn't take the initiative here and check it in as an
> obvious fix.
Really?
It's in Jim's area.
Jim tells me my patches aren't correct.
Don't you think "taking the initiative" and just up and checking it in would
step on his toes a little bit?
Believe it or not, I tried to avoid doing this when possible, which it
wasn't always in order to get stuff done.
We also had no clear ruling on the obvious fix rule yet, anyway.
Besides, if it's an obvious fix, why didn't he just take a few minutes to
look it over when it arrived in his inbox (you'll note the original
message was copied to him), and reply "looks okay"? Since if it's
obvious, it shouldn't take him more than probably 1 or 2 minutes to
look over a 20-30 line patch.
Just like a software project becomes late one day at a time, GDB is
improved one patch at a time.
If some of you maintainer guys and gals (i'm no longer a maintainer,
so it's not "we") ignore small patches (and i'm not implying any one
particular person does),
A. You won't get the effect a piling up of small improvements has.
B. You won't spur the people who made the small changes to make
larger, more ambitious ones.
I haven't touched the bcache since submitting that patch, and getting
no response. It's not because the bcache is perfect. It's because who
the heck wants to make large changes to anything if they'll just go
off into a void?
>
>
> Andrew
>
--
"I have two very rare photographs. One is a picture of Houdini
locking his keys in his car. The other is a rare photograph of
Norman Rockwell beating up a child.
"-Steven Wright
^ permalink raw reply [flat|nested] 21+ messages in thread