| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 16.1 | comments on issue 7 from David C. P. LaFrance-Linden | SMURF::LOWELL | | Thu Dec 05 1996 14:51 | 47 |
| 16.2 | Mangling not needed | VIRRUS::diewald | Here In Soap Opera Central... | Tue Dec 24 1996 14:12 | 16 |
| 16.3 | Comments from David C. P. LaFrance-Linden | SMURF::LOWELL | | Mon Dec 30 1996 11:44 | 14 |
| 16.4 | btArrayDesc not rich enough | NETRIX::"[email protected]" | David LaFrance-Linden | Tue Feb 04 1997 16:38 | 12 |
| This issue is raising its head again. See .3. Specifically, when
ladebug becomes the default debugger, the F90 compiler should by
default use btArrayDesc for array descriptors. Without a
backward-compatibility switch, this will break both Aardvark and
TotalView. But Aardvark and TotalView will resist switching to
btArrayDesc until there is a way to distinguish between assumed shape,
pointers and allocatables. With the $f90$f90_<type>_desc method, the
distinction is made and used.
Either somebody fixup btArrayDesc, or we're going to have competing
methods to accomplish similar means.
[Posted by WWW Notes gateway]
|
| 16.5 | | TLE::LUCIA | http://asaab.zko.dec.com/~lucia/biography.html | Wed Feb 05 1997 12:21 | 5 |
| What is the issue? Ladebug processes, displays, whatis's, etc. all of these
arrays, does it not? Is it that we don't say "pointer" or "allocatable" for the
output of whatis?
Tim
|
| 16.6 | The issue is loss of information | NETRIX::"[email protected]" | David LaFrance-Linden | Wed Feb 05 1997 13:05 | 18 |
| This issue is loss of information. Ideally, ladebug would say the
array is pointer or allocatable if either of those were the case. But
ladebug can't today because the information is lost. Aardvark and
TotalView (and others that might use the $f90$f90_<type>_desc
mechanism) do have the information.
The issue is that we have two methods for doing the same thing:
-- One method that loses information but is used by the
supplied-by-Digital debugger (ladebug), and
-- Another method that preserves the information used by an internal
debugger (Aardvark) as well as a blessed-by-Digital 3rd party
debugger (TotalView), and said method doesn't croak unaware
debuggers (dbx, gdb).
We should have one method used by all debuggers, ideally not croaking
unaware debuggers.
[Posted by WWW Notes gateway]
|
| 16.7 | | TLE::LUCIA | http://asaab.zko.dec.com/~lucia/biography.html | Tue Feb 25 1997 16:23 | 90 |
| There has been something bugging me since we last discussed this and only
yesterday I remembered what it was.
When Bob M. started re-using types in the aux table, ladebug broke on arrays,
because it saw it had already built a type [by only using the aux information]
and failed to incorporate the bounds. I.e., all arrays are 1:1 by 1, and then
the bounds follow. This breaks because ladebug will use the first array it sees
and the bounds for that array (which follow) are used for it, and all subsequent
arrays of the same type.
================================================================================
Note 5353.1 Incorrect debug information 1 of 1
GEMGRP::MONTELEONE 90 lines 11-JUL-1996 15:07
-< Not a GEM problem... >-
--------------------------------------------------------------------------------
This is a ladebug bug.
The symbol table is correct, just more compact. For some unobvious
reason, the legitimate reuse of an auxiliary symbol table sequence
causes ladebug to misbehave.
This symbol table produces correct results:
Binary of auxes:
0. 0x00000000 0x00000020 0x00000006 0x00000000 0x00000008
5. 0x00030008 0x00001fff 0x00000000 0x00000001 0x00000001
10. 0x00000001 0x0000000d 0x00000000 0x00000078 0x00000008
15. 0x00030008 0x00001fff 0x00000000 0x00000001 0x00000001
20. 0x00000001
Local Symbols:
from file 5353.for Printf aux if present
0. ( 0)( 0) 5353.for File Text symref 14
1. ( 1)(0x120001860) basictypes_ Proc Text [ 2] endref 6,btNil
2. ( 2)(0x24) Block Text symref 5
3. ( 3)(0x1400002a0) C1 Static Bss [ 5] Array
[(extended file 0, aux 1)1-1:1] of char
4. ( 2)(0x34) End Text symref 2
5. ( 1)(0x40) basictypes_ End Text symref 1
6. ( 1)(0x1200018a0) foo_ Proc Text [11] endref 13,btNil
7. ( 2)( 0x9) C Param VarRegister [15] Array
[(extended file 0,aux 1)1-1:1] of char
8. ( 2)(0xffffffffffffffa8) .ub_C.1 Local Abs [13]long
9. ( 2)(0xffffffffffffffd8) C.len Param Abs [13]long
10. ( 2)(0x28) Block Text symref 12
11. ( 2)(0x64) End Text symref 10
12. ( 1)(0x74) foo_ End Text symref 6
13. ( 0)( 0) 5353.for End Text symref 0
This symbol table triggers the bug:
Binary of auxes:
0. 0x00000000 0x00000020 0x00000006 0x00000000 0x00000008
5. 0x00030008 0x00001fff 0x00000000 0x00000001 0x00000001
10. 0x00000001 0x0000000d 0x00000000 0x00000078
Local Symbols:
from file 5353.for Printf aux if present
0. ( 0)( 0) 5353.for File Text symref 14
1. ( 1)(0x120001860) basictypes_ Proc Text [ 2] endref 6,btNil
2. ( 2)(0x24) Block Text symref 5
3. ( 3)(0x1400002a0) C1 Static Bss [ 5] Array
[(extended file 0, aux 1)1-1:1] of char
4. ( 2)(0x34) End Text symref 2
5. ( 1)(0x40) basictypes_ End Text symref 1
6. ( 1)(0x1200018a0) foo_ Proc Text [11] endref 13,btNil
7. ( 2)( 0x9) C Param VarRegister [ 5] Array
[(extended file 0, aux 1)1-1:1] of char
8. ( 2)(0xffffffffffffffa8) .ub_C.1 Local Abs [13] long
9. ( 2)(0xffffffffffffffd8) C.len Param Abs [13] long
10. ( 2)(0x28) Block Text symref 12
11. ( 2)(0x64) End Text symref 10
12. ( 1)(0x74) foo_ End Text symref 6
13. ( 0)( 0) 5353.for End Text symref 0
Note that the only difference is that the aux sequence associated with
symbols 3 and 7 are shared or "pooled." Since the sequence is
identical, this pooling is legitimate...
Although, dbx works, in one sense, with this case, I found another
problem, which can be reproduced with either symbol table:
|
| 16.8 | Partial catalog of well-known names | NNTPD::"[email protected]" | David LaFrance-Linden | Tue Apr 29 1997 12:50 | 139 |
| Here's my whack at things I know about. It's a lot longer than I thought!!
All:
main
Heck, if we're going to document them all...
The name of the program entrypoint, as assumed by __start() of
crt0.
_fpdata
A symbol whose existence, as far as I can tell, causes the
linker to preserve exception information and include exception
processing.
__init_<any>
__fini_<any>
__INIT_<key>_<any>
__FINI_<key>_<any>
Initialization and finish routines, which when global
functions are arranged by the linker to be called at program
startup and exit.
__StaticLink.<levelnum>
As we've been discussing.
Fortran:
MAIN__
The well-known alias of the fortran program unit, as known by
for_main (which contains the main() expected by __start() of
crt0).
_BLNK__
The name of the unnamed common block.
<ARGNAME>.len
Used in the calling sequence. These are additional ("hidden")
arguments that are passed when ARGNAME is of character type.
.lb_<ARRAYNAME>.<dimnum>
.ub_<ARRAYNAME>.<dimnum>
Lower and upper bounds of particular dimensions of arrays when
the array is explicit shape yet some bounds come from
non-constant specification expressions, used by array
arguments and automatic arrays.
$f90$f90_array_desc
$f90$f90_alloc_desc
$f90$f90_ptr_desc
Variants of F90 described arrays (assumed shape, ALLOCATABLE,
POINTER, respectively).
pointer
I believe these are typedef's for scalars with the POINTER
attribute.
cray_pointee
I've seen these recently. I believe these are typedef'd names
used by the pointee of cray pointers.
C:
...
to describe the '...' "argument" for functions taking a
variable argument list. The cc -migrate compiler on my DU
V3.2 machine no longer emits this as a parameter. That could
be considered a bug since the resulting parameter list is
incompletely specified.
C++:
$$elipses
The C++ compiler (T5.6-003) doesn't emit this as a parameter
any more. This could be considered a bug since the resulting
parameter list is incompletely specified. Instead, I did
find
__va_list_ptr1
and things like
_DECCXX_generated_name_a1cbdc10
this
The handle on the current instance. (Hey, it's a well-known
name!)
__vptr
__bptr
stMember's of btClass/stBlock's where the virtual function
table and virtual base class tables live. It's not clear the
types of these are accurate. E.g.,
__vptr |0x000000|Member |Virtual func table [int :0:32(64)]*|0x000008|
14|Info
__bptr |0x000040|Member |Virtual func table [int :0:2(64)]*|0x000008|
15|Info
bptr is NOT a virtual function table. The actual aux entry
(for the above __vptr) looks like:
(btVptr) (tqArray)(rfd=4095=0,idx=1)[0..32](bits/elt=64) (tqPtr)
which is a little bizzare, being a pointer to an array of
vptrs. I suspect this is why Dennis said the type isn't used
but rather debuggers key off the member name.
I suspect the following needn't be known by anybody, but you never
can tell!
__control
A hidden argument to constructors controlling descent (e.g.,
in the face of virtual base classes).
__vtbl_<manglings>
__btbl_<manglings>
Variables holding the virtual function table and virtual base
class tables. I believe the addresses of these things become
the __vtbl and __btbl of actual instances.
__t<num><no_idea>__evdf
I think these are compiler generated functions for
initializing constructors of global objects, and that these
are called by an __init_<...> routine the compiler also
generates for the file.
__t<num>_thunk
A compiler generated thunk, callable to provide a defaulted
argument value.
t<num><varname>__iviw
t<num><varname>__evdw
Functions(?) related to initializing top-level variables?
E.g.,
int a = some_function("Try me!");
__INTER__<bizarre>
Compiler-generated C++ interludes.
HPF:
You don't really want to know. Most of them involve #'s in their
names and are generally for conveying run-time distribution
information.
[Posted by WWW Notes gateway]
|
| 16.9 | | TLE::BRETT | | Fri May 16 1997 15:16 | 12 |
| I found these in Ladebug...
"this"
"<result_pointer>"
"__result_pointer")
"..."
"$$ellipsis"
"char"
without looking hard
/Bevin
|
| 16.10 | Nothing more to add from Gem... | GEMGRP::MONTELEONE | | Fri May 16 1997 16:29 | 4 |
|
Everything generated by Gem is described in David's note.
Bob
|