GDB has been having problems debugging shared libraries built with CVS 
gcc @ -O2. For example, libgcj backtraces look like this:

(gdb) bt
#0  _Jv_FindClass (name=0x83ebfe0, loader=Variable "loader" is not 
available.
) at ../../../libjava/java/lang/natClassLoader.cc:375
#1  0x01442a99 in _Jv_FindClassFromSignature (sig=Variable "sig" is not 
available.
) at ../../../libjava/prims.cc:753
#2  0x01442acb in _Jv_FindClassFromSignature (sig=Variable "sig" is not 
available.
) at ../../../libjava/prims.cc:757
#3  0x01467d61 in _Jv_PrepareCompiledClass (klass=0x18f3500) at 
../../../libjava/java/lang/natClassLoader.cc:107
#4  0x014670b8 in java::lang::Class::initializeClass (this=Variable 
"this" is not available.
) at ../../../libjava/java/lang/natClass.cc:733

The problem seems to be that dwarf2read.c does not offset 
dwarf2_loclist_baton's base_address for shared library load addresses. 
This means that find_location_expression() fails, since the unrelocated 
base_address in the baton does not match up with the PC being searched for.

Please review and commit. Since this bug means debugging of -O2 shared 
libraries with cvs GCC is basically broken, perhaps the fix should go on 
the stable branch as well?

Thanks to Daniel Berlin for helping to track this down!

Bryce