|
L. Livermore Laboratories has come across a program which adds an extra
level of complexity to this situation.
Consider the following program:
subroutine foo(px)
integer aaa(10),bbb(10)
pointer (px,aaa)
do i = 1, 10
bbb(i) = i * 100
end do
px = %loc(bbb(1))
print *,aaa
end
integer*8 x
call foo(x)
end
In essence, a cray pointer is being passed by reference. To properly
access the pointee, aaa, then, *two* levels of indirection are needed.
Currently, it is not possible to specify two level of indirection in
the symbol table. Lacking such a capability, the type of aaa is fudged
so that it is described as a pointer to an array to account for the
extra level of indirection.
Here is a correct symbol table, using the above approach:
SYMBOLS TABLE:
FILE 0. unmergable, preexisting, Fortran:
Binary of auxes:
0. 0x00000000 0x00000020 0x0000000a 0x00000000 0x00000078
5. 0x00030020 0x00004000 0x00000001 0x0000000a 0x00000004
10. 0x00130020 0x00004000 0x00000001 0x0000000a 0x00000004
15. 0x0000000f 0x00000000
Local Symbols:
from file aaa.f Printf aux if present
0. ( 0)( 0) aaa.f File Text symref 16
1. ( 1)( 0) foo_ Proc Text [ 2] endref 10, btNil
2. ( 2)( 0) cray pointee Typdef Info [10] Pointer to
Array [(file0, aux 4)1-10:4] of 32-bit long
3. ( 2)(0xffffffffffffffc8) PX Param Var [ 4]long
4. ( 2)(0x20) Block Text symref 9
5. ( 3)(0x1d0) I Static Bss [ 1] 32-bit long
6. ( 3)(0x1d4) BBB Static Bss [ 5] Array [(file 0,
aux 4)1-10:4] of 32-bit long
7. ( 3)(0xffffffffffffffc8) AAA Local Var [10]
Pointer to Array [(file 0, aux 4)1-10:4] of 32-bit long
8. ( 2)(0xc8) End Text symref 4
9. ( 1)(0xdc) foo_ End Text symref 1
10. ( 1)(0xdc) main$aaa_ Proc Text [15] endref 15, btNil
11. ( 2)(0x24) Block Text symref 14
12. ( 3)(0x200) X Static Bss [ 4] long
13. ( 2)(0x34) End Text symref 11
14. ( 1)(0x40) main$aaa_ End Text symref 10
15. ( 0)( 0) aaa.f End Text symref 0
Note the symbol table entry for the pointee, AAA:
7. ( 3)(0xffffffffffffffc8) AAA Local Var [10]
Pointer to Array [(file 0, aux 4)1-10:4] of 32-bit long
The symbol table class Var accounts for the first level of
indirection, the Pointer specification in the type, the other.
This is not a perfect representation, because AAA is not a pointer to
an array, just an array.
Upon linking this symbol table, I was surprised to see the stLocal
scVar combination worked ! I tried it with ladebug and it worked
correctly as well ! I am not sure whether this is by design or just
lucky, but both the linker and the debugger treat stLocal like stParam
in this case. If the symbol type were stStatic etc. the link would
fail.
Since it appears that stLocal can be paired with scVar and
scVarregister, we need to reach consensus that this combination
is indeed currently valid and document it as such.
The other issue that arises here is whether the current symbol
table representation for this case is adequate or not. If not,
then we need to design an approach to to allow two levels of
indirection.
Bob
|
| Bob Monteleone and I are exchanging mail around this.
From what I can tell, ladebug works ladebug works by
mistake, since it uses the stParam algorithm for some
stLocal cases; in parsesymscoff.C see
void ParseSymsCoff::readLocalSymbolInfo(pSYMR & sym,
...
case scVar: symbolDesc = d_refarg; break;
default: symbolDesc = d_localvar; break;
The 'mistake' could be in GEM in that it uses stParam for PX
but stLocal for AAA, yet the lsym.value are the same.
Stay tuned.
[Posted by WWW Notes gateway]
|
|
David is correct - ladebug works incorrectly and I incorrecttly
modified GEM to take advantage of the bug ! Of course, now that
I have corrected GEM to emit the proper offset for the stLocal scVar
combination, ladebug no longer works :^(.
Here is the apparent problem with ladebug. When a stLocal scVar
entry is encountered, ladebug interprets the value field (offset) of the
entry as if the symbol type were stParam and uses this formula to
determine the location of the symbol on the stack:
stack location offset = value field of symbol +
frame_size - argument_home_area_size
It should use the regular formula used to access locals:
stack location offset = value field of symbol +
frame_size - local_offset
GEM will emit the proper value in the value field of the symbol of
the stLocal scVar entry so that the latter formula can be applied to
correctly access the cray pointer parameter when the cray pointee
local symbol is referenced in the debuggers.
If we agree this is okay, then the only thing to be done is to fix
the debuggers.
Bob
|