[RFA v2] valprint.c / *-valprint.c: Don't lose `embedded_offset'

[Pedro Alves]

On Monday 24 January 2011 16:56:24, Joel Brobecker wrote:
> > > Joel, there are Ada changes in the patch, are those okay?
> 
> Hi Pedro. The changes look sane to me. There was only one place where
> the offset was missing, affecting packed records.  Patch attached.

Thank you!  I've committed the patch with that change in.

> I wish we could allow everyone to get a clean run in gdb.ada,
> it really sucks :-(.  

Yeah...  :-(

> I tried to speed things up a bit on the compiler
> side with the descriptive-type stuff, but it's very very hard to get
> feedback from maintainers who have the power to approve or make
> suggestions...  I need to check with Olivier, but he might have given
> up on it :-(.

Ah, so you're saying that most of the failures we get with FSF
gnat are related to some sort descriptive-type debug info support
or something like that, I guess?

Here's the current set of Ada fails I get:
 
 FAIL: gdb.ada/array_bounds.exp: print table'first
 FAIL: gdb.ada/array_bounds.exp: print table'last
 FAIL: gdb.ada/arrayidx.exp: print e_one_two_three, indexes off
 FAIL: gdb.ada/arrayidx.exp: print r_two_three, indexes off
 FAIL: gdb.ada/arrayidx.exp: print e_one_two_three
 FAIL: gdb.ada/arrayidx.exp: print r_two_three
 FAIL: gdb.ada/catch_ex.exp: insert catchpoint on all Ada exceptions
 FAIL: gdb.ada/catch_ex.exp: info break, catch all Ada exceptions
 FAIL: gdb.ada/catch_ex.exp: continuing to first exception (the program exited)
 FAIL: gdb.ada/catch_ex.exp: continuing to second exception (the program is no  
longer running)
 FAIL: gdb.ada/catch_ex.exp: insert catchpoint on Program_Error
 FAIL: gdb.ada/catch_ex.exp: insert catchpoint on failed assertions
 FAIL: gdb.ada/catch_ex.exp: insert catchpoint on unhandled exceptions
 FAIL: gdb.ada/catch_ex.exp: info break, second run
 FAIL: gdb.ada/catch_ex.exp: continuing to Program_Error exception (the  
program exited)
 FAIL: gdb.ada/catch_ex.exp: continuing to failed assertion (the program is no  
longer running)
 FAIL: gdb.ada/catch_ex.exp: continuing to unhandled exception (the program is  
no longer running)
 FAIL: gdb.ada/catch_ex.exp: continuing to program completion (the program is  
no longer running)
 FAIL: gdb.ada/dyn_loc.exp: info locals
 XFAIL: gdb.ada/null_array.exp: print my_table
 FAIL: gdb.ada/null_array.exp: ptype my_table
 FAIL: gdb.ada/packed_tagged.exp: print x
 FAIL: gdb.ada/taft_type.exp: print w.e.all

Many of the failures look indeed related to something not
mapping integers to descriptive names (somewhat like
enums)?  I'm clueless about Ada...

Maybe we could catch these cases and KFAIL them instead of
FAILing?


Looking at  the log of a couple of odd ones:

 (gdb) catch exception
 Cannot insert catchpoints in this configuration.
 (gdb) FAIL: gdb.ada/catch_ex.exp: insert catchpoint on all Ada exceptions
 info break
 Num     Type           Disp Enb Address            What
 1       breakpoint     keep y   0x0000000000401495 in main at  
/home/pedro/gdb/tdd_upstream/build/gdb/testsuite/gdb.ada/catch_ex/b~foo.adb:110
         breakpoint already hit 1 time
 (gdb) FAIL: gdb.ada/catch_ex.exp: info break, catch all Ada exceptions
 continue
 Continuing.

 raised CONSTRAINT_ERROR : foo.adb:41 explicit raise

 Program exited with code 01.
 (gdb) FAIL: gdb.ada/catch_ex.exp: continuing to first exception (the program 
exited)
 continue
 The program is not being run.
 (gdb) FAIL: gdb.ada/catch_ex.exp: continuing to second exception (the program 
is no longer running)

(and other similar cascaded FAILs).  Maybe we should handle the
missing support gracefully, and bail out unsupported?

And this one:

 Breakpoint 1, p () at  
/home/pedro/gdb/tdd_upstream/src/gdb/testsuite/gdb.ada/taft_type/p.adb:22
 22      end P;  --  START
 (gdb) print w.e.all
 No definition of "w.e" in current context.
 (gdb) FAIL: gdb.ada/taft_type.exp: print w.e.all

Maybe a test bug?

-- 
Pedro Alves