GDB respin

GDB respin

[Andrew Cagney]

Hello,

Should there be a 5.3.1.  So far not much has been comitted to the 
branch.  However, there have been a number of configure / build bug reports.

If nothing else, I'll raise this question again in a month and then 
declare the branch dead.

Andrew

Re: GDB respin

[Michael Elizabeth Chastain]

[I'm partially back.  I can read my mail, and I can run my test bed,
 but I'm not caught up on stuff.  -- Michael C]

Andrew Cagney asks:
> Should there be a 5.3.1.  So far not much has been comitted to the 
> branch.  However, there have been a number of configure / build bug reports.

My preference would be to not produce 5.3.1.  It seems like a low-yield
use of resources to me.

Are the configure/build problems fixed in HEAD?

For those problems which are not fixed in HEAD:
  we need to do that anyways, no matter what

For those problems which are fixed in HEAD:
  ask the bug report submitters to try a HEAD snapshot
  put the PR's into 'FEEDBACK' state

Anyways, I will keep testing and reporting on gdb_5_3-branch.
My test bed role is separate from my loudmouth role.

Michael C

Re: GDB respin

[Andrew Cagney]

> [I'm partially back.  I can read my mail, and I can run my test bed,
>  but I'm not caught up on stuff.  -- Michael C]
> 
> Andrew Cagney asks:
> 
>> Should there be a 5.3.1.  So far not much has been comitted to the 
>> branch.  However, there have been a number of configure / build bug reports.
> 
> 
> My preference would be to not produce 5.3.1.  It seems like a low-yield
> use of resources to me.
> 
> Are the configure/build problems fixed in HEAD?

No.  Check the bug database for `high' priority `build' problems.

> For those problems which are not fixed in HEAD:
>   we need to do that anyways, no matter what
> 
> For those problems which are fixed in HEAD:
>   ask the bug report submitters to try a HEAD snapshot
>   put the PR's into 'FEEDBACK' state
> 
> Anyways, I will keep testing and reporting on gdb_5_3-branch.
> My test bed role is separate from my loudmouth role.

:-)

In fact, if the console problem can be resolved, I think there is a very 
strong incentive to quickly spin out a 5.4.

Andrew

Re: GDB respin

[Quality Quorum]

On Thu, 30 Jan 2003, Andrew Cagney wrote:

> In fact, if the console problem can be resolved, I think there is a very
> strong incentive to quickly spin out a 5.4.

Releases are multiplied like rabbits :). If we are going thorugh big
releases anyway, it may seem cost effective to refactor gdb into C++, using
the real thing would save a lot of time in the long run comparing
with constant grappling with poor man's c++.

> Andrew

Thanks,

Aleksey

Re: GDB respin

[Michal Ludvig]

Andrew Cagney wrote:

> I think there is a very 
> strong incentive to quickly spin out a 5.4.

After merging i386 and x86-64 we need some more time to make HEAD at 
least as stable as 5.3 is. For now too many testsuites fail in HEAD.

Michal Ludvig
-- 
* SuSE CR, s.r.o     * mludvig@suse.cz
* (+420) 296.545.373 * http://www.suse.cz

Re: GDB respin

[Michael Elizabeth Chastain]

> In fact, if the console problem can be resolved, I think there is a very 
> strong incentive to quickly spin out a 5.4.

Okay, on my next spin I will go through the 'Compare by GDB' table and
chase down all the differences and write a report on 5.3 versus HEAD.

My recollection is that there aren't any serious problems, at least in
the parts I cover.  Which is like saying that New York City doesn't have
a serious crime problem in the area between 40th and 60th streets and
3rd and 8th avenues.  :)

gdb.base/testsuite and gdb.c++/testsuite have no gdb regressions between
5.3 and 2003-01-20.

There are some new tests in gdb.base/advance.exp and gdb.base/until.exp
that FAIL with gcc v3, but that is a problem with the tests rather than
gdb.  Briefly, after the return from a call to 'foo();', the current
line might be on line N or on line N+1 depending on the compiler, but
the test script always expects to be on line N.  The cheesy way out
would be to change the program-under-test to 'foo(), bar();' with a
comma operator to force a sequence point.

One issue is that all the MI tests got shuffled so that every MI
non-PASS might be a regression or might not be.  Someone has to look at
the MI results on four configurations (gcc v2/v3 and dwarf-2/stabs+) and
say whether they are must-fix or not.

Michael C

Re: GDB respin

[Michael Elizabeth Chastain]

Hi Michal,
> After merging i386 and x86-64 we need some more time to make HEAD at 
> least as stable as 5.3 is. For now too many testsuites fail in HEAD.

Can you give more detail on that?  Which platforms are you seeing
testsuite trouble with?

On native i686-pc-linux-gnu, my test suite results have few new
problems from 5.3 to HEAD.

Michael C

Re: GDB respin

[Michael Elizabeth Chastain]

Michal Ludvig mailed me some gdb.log files for x86_64 and I had
a superficial look.  This is for gdb:

  GNU gdb 2003-02-01-cvs
  Copyright 2003 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for details.
  This GDB was configured as "x86_64-unknown-linux-gnu".

This gdb has some new internal errors.
All of these are new, compared to gdb 5.3.

     49	gdb.log:../../gdb-head/gdb/sentinel-frame.c:102: internal-error: Function sentinal_frame_pop called
      3	gdb.log:../../gdb-head/gdb/regcache.c:713: internal-error: regcache_raw_read: Assertion `regcache != NULL && buf != NULL' failed.
      5	gdb.log:../../gdb-head/gdb/gdbarch.c:4271: internal-error: gdbarch: gdbarch_store_return_value invalid
      2	gdb.log:&"../../gdb-head/gdb/gdbarch.c:4252: internal-error: gdbarch: gdbarch_extract_return_value invalid\n"
      6	gdb.log:../../gdb-head/gdb/gdbarch.c:4252: internal-error: gdbarch: gdbarch_extract_return_value invalid

The first number is a count.  So there were 49 instances of
'internal-error: Function sentinal_frame_pop' called.

Can anyone speak to these internal-errors?  
Do some of them have obvious easy fixes?

Michael C

Re: GDB respin

[Andrew Cagney]

Can someone post backtraces?

      49	gdb.log:../../gdb-head/gdb/sentinel-frame.c:102: 
internal-error: Function sentinal_frame_pop called

Er, this should shouldn't happen.  Backtrace?

       3	gdb.log:../../gdb-head/gdb/regcache.c:713: internal-error: 
regcache_raw_read: Assertion `regcache != NULL && buf != NULL' failed.

Again, the caller is pretty messed up.

       5	gdb.log:../../gdb-head/gdb/gdbarch.c:4271: internal-error: 
gdbarch: gdbarch_store_return_value invalid
       2	gdb.log:&"../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
gdbarch: gdbarch_extract_return_value invalid\n"
       6	gdb.log:../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
gdbarch: gdbarch_extract_return_value invalid


Andrew

Re: GDB respin

[Elena Zannoni]

Andrew Cagney writes:
 > Can someone post backtraces?
 > 
 >       49	gdb.log:../../gdb-head/gdb/sentinel-frame.c:102: 
 > internal-error: Function sentinal_frame_pop called
 > 
 > Er, this should shouldn't happen.  Backtrace?
 > 
 >        3	gdb.log:../../gdb-head/gdb/regcache.c:713: internal-error: 
 > regcache_raw_read: Assertion `regcache != NULL && buf != NULL' failed.
 > 
 > Again, the caller is pretty messed up.
 > 
 >        5	gdb.log:../../gdb-head/gdb/gdbarch.c:4271: internal-error: 
 > gdbarch: gdbarch_store_return_value invalid
 >        2	gdb.log:&"../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
 > gdbarch: gdbarch_extract_return_value invalid\n"
 >        6	gdb.log:../../gdb-head/gdb/gdbarch.c:4252: internal-error: 
 > gdbarch: gdbarch_extract_return_value invalid
 > 
 > 
 > Andrew
 > 

I have an x86_64 machine I can try this on as well. It will have to be later
today though.

elena