Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release

[Daniel Berlin <dan at cgsoftware dot com>]

> 
> First, Sam's patches just follow what is in solib.c. 
How so?

Their is not any other function in there to determine consistency or
status of libraries.

Sam's is a new type of hook.
Furthermore, i don't see how it's necessary.
Why did he add this consistency hook, to fix a problem that occurs when
you restart.
Why not implement the SOLIB_REMOVE_INFERIOR hook, and rather than the
other implementations, which say they don't disable the breakpoints
(mainly because of their own reasons), disable the breakpoints in those
shared libs.

Does this hook Sam added help anyone else, or add functionality that is
useful to anyone else?
Not really.


 > I don't
think
he > instroduced a new kind of hack. 

He did. There were no other "hacks" to determine whether a list of solibs
was consistent.


> Unless we remove all those "hacks" in
> solib.c in gdb 5.0, I don't think it is a good excuse not to fix the
> bug. 

This is the eventual goal.
Can this bug not be fixed without adding that hook?

>For whoever has to cleanup the "mess" in solib.c, it is just
> another item on the check list. 

So as long as it's an SEP (Someone Elses Problem), it's fine.

And what happens when this hook gets removed in 2 months?
Do you expect the person who removes it, cleaning up solib.c, to fix the
problem the right way then?
> It is the time to make gdb more usable
> than make our lives easier. 
> I hate to see people say gdb 5.0 doesn't
> work right with shared libraries on Linux. 
So fix it without adding another fricking hack.
How do you think things got the way they are in terms of hacks in the
code?
Nobody ever had the time to do the cleanup, instead spending the time on
making it more usable and making lives easier. 
(Not to mention the HP merge, but that's not exactly a standard event)
Don't you understand that?
Unless someone says "enough is enough, i'm putting my foot down, stop
adding hacks, it's becoming unmanageable", it becomes (surprise!)
unmanageable.
 > I'd like to see a firm date
> when the support in gdb for shared libraries will be fixed.

It's funny.
It seems every other platform is making do without this "fix", AFAICT by
bug reports.

> At least,
> I can tell people it will work in xxxx, 2000 and I don't have to make
> my gdb available for Lunux again.


> 
> 
> H.J.
>