GDB 7.0.90 available for testing

GDB 7.0.90 available for testing

[Joel Brobecker]

Hello,

I have just finished creating the gdb-7.0.90 pre-release.
It is available for download at the following location:

    ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.0.90.tar.bz2

A gzip'ed version is also available: gdb-7.0.90.tar.gz.

Please give it a test if you can and report any problems you might find.

On behalf of all the GDB contributors, thank you!

-- 
Joel

Re: GDB 7.0.90 available for testing

[Ralf Corsepius]

On 02/19/2010 02:20 AM, Joel Brobecker wrote:
> Hello,
>
> I have just finished creating the gdb-7.0.90 pre-release.
> It is available for download at the following location:
>
>      ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.0.90.tar.bz2
>
> A gzip'ed version is also available: gdb-7.0.90.tar.gz.
>
> Please give it a test if you can and report any problems you might find.

While test-building gdb-7.0.90 packages for RTEMS, I noticed gdb's 
configure scripts doesn't seem to be detecting invalid targets.

For example configure accepts --target=bfin-rtems4.10 without any 
complaint and subsequently builds binaries.

However these binaries fail badly at run-time:

# bfin-rtems4.10-gdb
../../gdb-7.0.90/gdb/arch-utils.c:648: internal-error: 
initialize_current_architecture: Selection of initial architecture failed
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
../../gdb-7.0.90/gdb/arch-utils.c:648: internal-error: 
initialize_current_architecture: Selection of initial architecture failed
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]
Aborted (core dumped)

[A far as bfin-* targets are concerned, this issue already existed in 
previous gdb-versions.]

Ralf

Re: GDB 7.0.90 available for testing

[Joel Brobecker]

> For example configure accepts --target=bfin-rtems4.10 without any
> complaint and subsequently builds binaries.

I think that's a known situation - we don't check the correctness of
the target triplet - often the configure just assumes one of the
bareboard variants but that's highly speculative at best. when you're lucky,
you'll see an error message during the GDB configure, but otherwise,
yeah, GDB will fail at build time.

-- 
Joel

Re: GDB 7.0.90 available for testing

[Ralf Corsepius]

On 02/19/2010 05:33 PM, Joel Brobecker wrote:
>> For example configure accepts --target=bfin-rtems4.10 without any
>> complaint and subsequently builds binaries.
>
> I think that's a known situation
I guessed as much - binutils and gcc are more restrictive, ... and 
unless I am in error, gdb once also was :(

> - we don't check the correctness of
> the target triplet - often the configure just assumes one of the
> bareboard variants but that's highly speculative at best. when you're lucky,
> you'll see an error message during the GDB configure, but otherwise,
> yeah, GDB will fail at build time.

Note: It did not fail at build-time - Building went absolutely 
smoothless -- gdb crashed at run-time!

Ralf

Re: GDB 7.0.90 available for testing

[Joel Brobecker]

> I guessed as much - binutils and gcc are more restrictive, ... and
> unless I am in error, gdb once also was :(

I don't remember that it was, but I might be wrong.  GDB is unfortunately
one of these projects where a lot of knowledge is undocumented.  We are
trying to be better, by documenting any convention and decision that
we make, but it's still far from perfect.

> Note: It did not fail at build-time - Building went absolutely
> smoothless -- gdb crashed at run-time!

Right - I meant run-time, not build-time.

I don't feel like this is a real problem, but others might disagree.

-- 
Joel

Re: GDB 7.0.90 available for testing

[Ralf Corsepius]

On 02/19/2010 05:52 PM, Joel Brobecker wrote:
>> I guessed as much - binutils and gcc are more restrictive, ... and
>> unless I am in error, gdb once also was :(
>>      
> I don't remember that it was, but I might be wrong.
Well, in my case, it's only the bfin which exposes this behavior.

IIRC, in case of bfin-* targets, gdb < 7's configure-scripts refused to 
buildbfd, opcodes or some other binutils subdirectory, gdb inherits from 
binutils. AFAIS, gdb >= 7.0 has inherited bfd etc. from a version of 
binutils which has been added the bfin* targets.

I.e. now, binutils' more restrictive checks don't trigger anymore.

>> Note: It did not fail at build-time - Building went absolutely
>> smoothless -- gdb crashed at run-time!
>>      
> Right - I meant run-time, not build-time.
>
> I don't feel like this is a real problem, but others might disagree.
>    
Well, it's certainly not a major issue, nevertheless it's a nuissance 
responsible for nasty surprises and thus should be addressed.

Ralf