| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 908.1 | | TLE::LUCIA | http://asaab.zko.dec.com/~lucia/biography.html | Thu Apr 03 1997 17:37 | 3 |
| Can you point us at the binary so we can reproduce the problem?
Tim
|
| 908.2 | | TLE::LUCIA | http://asaab.zko.dec.com/~lucia/biography.html | Fri Apr 04 1997 12:00 | 41 |
| I have reproduced this. Has something to do with nesting of scopes. I don't
know exactly what yet, but it smells like an invalid symbol table.
Local Symbols:
from file ./cxxl_init.cxx Printf aux if present
0. ( 0)( 0) ./cxxl_init.cxx File Text symref 28
1. ( 1)(0x140002a50) __cxxl_init_object Static Bss [13] struct(file
1, index 2)
2. ( 1)(0x140002a58) iostream_init Static Bss [13] struct(file 1,
index 2)
3. ( 1)(0x120018dd0) __cxxl_init(void) Proc Text [15] endref 7, int
4. ( 2)( 0) Block Text symref 6
5. ( 2)( 0x4) End Text symref 4
6. ( 1)( 0x8) __cxxl_init(void) End Text symref 3
7. ( 1)(0x120018bc0) __init_sti____cxxl_init_cxx___init_init(void) Proc
Text [17] endref 11, void
8. ( 2)(0x14) Block Text symref 10
9. ( 2)(0xec) End Text symref 8
10. ( 1)(0xfc) __init_sti____cxxl_init_cxx___init_init(void) End Text
symref 7
11. ( 1)(0x120018cd0) StaticProc Text [19] endref 15, void
12. ( 2)(0x1c) Block Text symref 14
13. ( 2)(0x2c) End Text symref 12
14. ( 1)(0x34) End Text symref 11
15. ( 1)(0x120018d10) StaticProc Text [21] endref 19, void
16. ( 2)(0x1c) Block Text symref 18
17. ( 2)(0x2c) End Text symref 16
18. ( 1)(0x34) End Text symref 15
19. ( 1)(0x120018d50) StaticProc Text [23] endref 23, void
20. ( 2)(0x1c) Block Text symref 22
21. ( 2)(0x30) End Text symref 20
22. ( 1)(0x38) End Text symref 19
23. ( 1)(0x120018d90) StaticProc Text [25] endref 27, void
24. ( 2)(0x1c) Block Text symref 26
25. ( 2)(0x2c) End Text symref 24
26. ( 1)(0x34) End Text symref 23
27. ( 0)( 0) ./cxxl_init.cxx End Text symref 0
The 26th entry (th END for the StaticProc at 23) is not closing the list of
scopes correctly. This is just an update. Someone will look into this further.
|
| 908.3 | Blame me | CXXC::MJHANS | Matthew Hanselman, DEC C/C++ | Mon Apr 07 1997 17:59 | 4 |
| I've verified it's probably something I'm doing wrong -- I'll take it
from here.
- Matt
|
| 908.4 | | CXXC::MJHANS | Matthew Hanselman, DEC C/C++ | Mon Apr 07 1997 18:56 | 9 |
| This problem existed because V6.0 was generating namespace TDIs. Since
neither ladebug nor stdump knows about namespace TDIs, it looked very
much like a totally wrong DST was being generated.
I've disabled namespace TDI generation for the time being; I'll
re-enable it when we install a ladebug that can handle namespace TDIs.
I didn't realize we already had code that used namespaces.
- Matt
|
| 908.5 | | TLE::LUCIA | http://asaab.zko.dec.com/~lucia/biography.html | Tue Apr 08 1997 18:40 | 3 |
| The problem is with "unnamed static procs". Ladebug intentionally ignores any
unnamed symbol, since it is useless to the user. It doesn't know about the
corresponding ENDs and so it pops too many scopes.
|
| 908.6 | | CXXC::MJHANS | Matthew Hanselman, DEC C/C++ | Fri Apr 18 1997 11:06 | 11 |
| We're working on naming all of our compiler-generated routines. This
problem should fall out when this happens.
However, it is perfectly legal to have unnamed static procedures in
your object file -- however, the user would never be able to make one
themselves, and should't care about what's going on inside them. To make
ladebug more "bulletproof", I'd suggest rigging ladebug so it won't die
on these cases -- probably making it know to completely ignore unnamed
routines.
- Matt
|