[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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 |
959.0. "Assertion tripped when processing ELLIPSIS parameter" by GEMGRP::MONTELEONE () Tue May 20 1997 16:46
I am working on debug support for processing an "unspecified number of
arguments" (i.e. "...") and came across the following problem with the V5.1
ucode C++ compiler. The problem does not occur with GEM based compilers
because such support is not yet implemented in them. Since I am working
towards such support, it would be nice to have the debugger behave
properly.
int foo(...);
int foo(int fooparam,int barparam,...) {
return 3;
}
int main () { return foo(1,2,3); }
whipit> lad e_old.out
Welcome to the Ladebug Debugger Version 4.0-36
------------------
object file name: e_old.out
Reading symbolic information ...done
(ladebug) bp foo
[#1: stop in int foo(int, int, ...) ]
(ladebug) r
[1] stopped at [int foo(int, int, ...):6 0x1200020c0]
6 return 3;
(ladebug) where
>0 0x1200020c0 in foo(fooparam=1, barparam=2, $$ellipsis=Invalid
symbol descrip
tor d_ellipsis for symbol $$ellipsis in Symbol::value(Frame*)
Assertion failed: locp != NULL src/libsrc/ladebug/symbol.C 1193
This is an unexpected condition and may indicate the presence of a
defect.
If you wish to report this, please include the stack trace that
follows.
Diagnostic stack trace ...
0x123ba9a8
0x123be070
0x1229a30c
0x1229b6f8
0x1229b174
0x1229b7ec
0x1229be50
0x12232ac4
0x122370b0
0x122270fc
0x1222423c
end of diagnostic stack trace.
Here is the symbol table - the $$ellipsis symbol is the symbol
of interest:
Binary of auxes:
0. 0x00000000 0x00000018 0x00000009 0x00000018 0x00000018
5. 0x0000000e 0x00000018
Local Symbols:
from file ellip.cxx Printf aux if present
0. ( 0)( 0) ellip.cxx File Text symref 15
1. ( 1)(0x1200020b0) foo(int, int, ...) Proc Text [ 2]
endref 9, int
2. ( 2)( 0) fooparam Param Abs [ 4] int
3. ( 2)( 0x8) barparam Param Abs [ 4] int
4. ( 2)( 0xc) $$ellipsis Param Abs indexNil
**********************************************************
5. ( 2)(0x10) Block Text symref 8
6. ( 3)( 0x1) <RESULT> Local Register indexNil
7. ( 2)(0x20) End Text symref 5
8. ( 1)(0x2c) foo(int, int, ...) End Text symref 1
9. ( 1)(0x1200020e0) main Proc Text [ 5] endref 14,
int
10. ( 2)(0x18) Block Text symref 13
11. ( 3)( 0x9) <RESULT> Local Register indexNil
12. ( 2)(0x48) End Text symref 10
13. ( 1)(0x60) main End Text symref 9
14. ( 0)( 0) ellip.cxx End Text symref 0
The value field of the symbol is a little suspect and I am going
to clairfy this format via the Symbol Table Working Group; however
ladebug should not assert, regardless.
I have a V51 C++ ucode based compiler handy - let me know if you
need it...
Bob
T.R | Title | User | Personal Name | Date | Lines |
---|
959.1 | The storage class doesn't look good either... | GEMGRP::MONTELEONE | | Tue May 20 1997 18:02 | 9 |
|
On further thought, the scAbs associated with $$ellipsis is probably
inappropriate as well. I still contend the debugger should do something
other than assert, though...
Bob
|