| Title: | Digital Ladebug debugger |
| Moderator: | TLE::LUCIA |
| Created: | Fri Feb 28 1992 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 969 |
| Total number of notes: | 3959 |
This actually doesn't really fail under UNIX, and I'd understand an
argument to just leave it. But here goes:
If you have an array definition in one shared object, its type will be
incorrectly reported if you're in another shared object that declared it
incompletely.
Take the C files at the bottom of this message, compile as follows:
cc -g -O0 -shared -rpath . -o 1.so 1.c
cc -g -O0 -shared -rpath . -o 2.so 2.c
cc -g -O0 1.so 2.so
If while in main() you do a "whatis element_array", it'll report an
array of length 0. This is because the compiler doesn't know anything
about the array at compile-time, and generates an array of length 0 and
stride 0. Since it's not linked together with the file with the
definition, the DST entry is left alone.
I'd be inclined to have ladebug search across shared objects if the
array DST entry it finds has the properties of an incomplete
array (type).
Note that you can still view the data in element_array, because ladebug
is smart enough not to impose array bound-checking on you (VMS does).
Hence why it doesn't "really" fail.
- Matt
/* 1.c */
int element_array[6];
/* 2.c */
extern int element_array[];
int main ()
{
element_array[4] = 4 ;
}
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 921.1 | QUARRY::petert | rigidly defined areas of doubt and uncertainty | Thu Apr 10 1997 11:34 | 33 | |
I think it's a bug. This will work under dbx (and I'm supposed to report these differences, right? ;-) Here's what I get with your example: petert@deneb 43> cc -g -O0 -shared -rpath . -o 1.so 1.c petert@deneb 44> cc -g -O0 -shared -rpath . -o 2.so 2.c ld: Warning: Unresolved: element_array petert@deneb 45> cc -g -O0 1.so 2.so -o 12 petert@deneb 46> dbx 12 dbx version 3.11.12 Type 'help' for help. (dbx) whatis element_array element_array[6] of int ; (dbx) q petert@deneb 47> ladebug 12 Welcome to the Ladebug Debugger Version 4.0-35 ------------------ object file name: 12 Reading symbolic information ...done (ladebug) whatis element_array array [subrange 0 ... 0 of long] of int element_array (ladebug) q What I'm trying to figure out, by looking for older versions of dbx, is whether this was resolved by some of the work I did for resolving common blocks for fortran, which got even a bit more involved. But as far back as the version I have for V3.2, this seems to work. PeterT | |||||
| 921.2 | CXXC::MJHANS | Matthew Hanselman, DEC C/C++ | Thu Apr 10 1997 11:56 | 15 | |
> I think it's a bug. This will work under dbx (and I'm supposed to report
> these differences, right? ;-)
I didn't think of trying that. :)
I'd like to point out that there is actually a bug in the current DEC C
and DEC C++ compilers, in that the stride for an incomplete array
should NOT be 0 -- it should be the real stride (as that is available
to all files at compile-time).
So an incomplete array is known only in that its length is 0.
I've fixed the bug in the compilers.
- Matt
| |||||