Re: [rfc] 'union' handling for Fortran (in GDB)

[Daniel Jacobowitz <drow at false dot org>]

I can't make a sensible decision about this; I know roughly nothing
of what Fortran programmers would expect.  So I'm copying your message
to the GCC Fortran list, and I hope someone there has a suggestion.

For fortran@, the context starts here:
  http://sourceware.org/ml/gdb-patches/2007-06/msg00131.html

The SPU has a number of vector registers.  Their type is represented
in GDB as a union of useful views.  When you're in Fortran mode,
there's no way to handle unions, and it's hard to see the registers.

I think that we could add union handling if someone familiar with
Fortran wants to pick a fake syntax, suitably unlikely to mean
something in a later revision of Fortran, or something equivalent from
the current Fortran.  Equivalences don't seem to be quite the same
thing.

Or we could come up with an entirely different way to represent vector
registers in GDB.  The current representation is not very helpful
sometimes.  Maybe we should display the register in only one type
by default, as a giant hex string, and provide built-in functions
to convert it to other types.

I'm open to ideas :-)

On Wed, Jun 13, 2007 at 06:29:11PM +0200, Markus Deuling wrote:
> This is a test with spu-gdb debugging a C application:
> 
> (gdb) br main
> Breakpoint 1 at 0x4dc: file break_spu_bin.c, line 10.
> (gdb) r
> Starting program: /home/deuling/simple/break_spu_bin
> 
> Breakpoint 1, main (speid=4294967296, argp=1125693748412416, envp=0)
>    at break_spu_bin.c:10
> 10        printf("Hello World! from spu\n");
> (gdb) set language fortran
> Warning: the current language does not match this frame.
> (gdb) p $r1
> $1 = {uint128 = 0x0003ff700003f2500003ff700003ff70,
>  v2_int64 = (1125281431810640, 1125281431814000),
>  v4_int32 = (262000, 258640, 262000, 262000),
>  v8_int16 = (3, -144, 3, -3504, 3, -144, 3, -144),
>  v16_int8 = (0 '\000', 3 '\003', -1 '???', 112 'p', 0 '\000', 3 '\003', -14 
> '???', 80 'P', 0 '\000', 3 '\003', -1 '???', 112 'p', 0 '\000', 3 '\003', -1 
> '???', 112 'p'), v2_double = (5.5596289736068649e-309, 
> 5.5596289736234655e-309),
>  v4_float = (3.67140198e-40, 3.62431835e-40, 3.67140198e-40, 3.67140198e-40)}
> (gdb) ptype $r1
> type = union __spu_builtin_type_vec128 {
>    int128_t uint128;
>    int64_t v2_int64[2];
>    int32_t v4_int32[4];
>    int16_t v8_int16[8];
>    int8_t v16_int8[16];
>    double v2_double[2];
>    float v4_float[4];
> }spu_builtin_type_vec128
> (gdb)
> 
> 
> Yes, you're right. The fortran programmer will wonder what that means :-) But I 
> guess it's better
> than an error message like
> (gdb) p $r1
> $2 = <error reading variable> 
> 
> And yes, when language is set to fortran you can't access union members with 
> out changes in the parser.
> 
> (gdb) p $r1.v4_float[0]
> A syntax error in expression, near `.v4_float[0]'.
> (gdb) set language c
> (gdb) p $r1.v4_float[0]
> $2 = 3.67140198e-40
> (gdb)
> 
> Any Ideas on that ? Shall I do that changes to the parser ?!?

-- 
Daniel Jacobowitz
CodeSourcery