- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi!
It's a continuation of my earlier asked question, and addressed mainly to Steve Lionel.
Why debugging information about common blocks in pdb files don't have any logic?
If I write some sing in my source, why it not reflect in debugging info?
I see sections with names looks like a common names, but parent object is *LINKER* (or something like that).
If I export an common the section lose the size, _ in name, and obtain another type. Why?
When I analogize obj files, I using COFF symbols, CV symbols, and all works properly, now it's a really hard stuff. I'm understand that commons is a archaic structure, but all old codes works on it.
It's a continuation of my earlier asked question, and addressed mainly to Steve Lionel.
Why debugging information about common blocks in pdb files don't have any logic?
If I write some sing in my source, why it not reflect in debugging info?
I see sections with names looks like a common names, but parent object is *LINKER* (or something like that).
If I export an common the section lose the size, _ in name, and obtain another type. Why?
When I analogize obj files, I using COFF symbols, CV symbols, and all works properly, now it's a really hard stuff. I'm understand that commons is a archaic structure, but all old codes works on it.
Message Edited by intel.software.network.support on 12-09-2005 01:52 PM
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, I don't understand the COFF object format. We have other people who handle that sort of thing. I'm also not sure if the debug info is considered a public interface.
You can view COMMON variables in the debugger, so clearly the info is there in a format that the debugger understands. It should be the same general mechanism MSVC uses for externs.
Steve
You can view COMMON variables in the debugger, so clearly the info is there in a format that the debugger understands. It should be the same general mechanism MSVC uses for externs.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, I don't understand the COFF object format.
You are not alone :)
We have other people who handle that sort of thing. I'm also not sure if the debug info is considered a public interface.
It's a public interface, but not considered.
You can view COMMON variables in the debugger, so clearly the info is there in a format that the debugger understands. It should be the same general mechanism MSVC uses for externs.
Not quite right, and it's a main problem. In debugger you can view LOCAL variables, and can't view common block structure. "In different modules common may has different structure" you may say, BUT if you define the same common in different modules whith differ arrays (for example), you may see in debugger different sizes of arrays whith one name in different modules, and what about commons?
And another one bug, if you type in watch common name whith leading _, debugger show strange value (first item in common in hexadecimal form), and where this symbol in source code?
You are not alone :)
We have other people who handle that sort of thing. I'm also not sure if the debug info is considered a public interface.
It's a public interface, but not considered.
You can view COMMON variables in the debugger, so clearly the info is there in a format that the debugger understands. It should be the same general mechanism MSVC uses for externs.
Not quite right, and it's a main problem. In debugger you can view LOCAL variables, and can't view common block structure. "In different modules common may has different structure" you may say, BUT if you define the same common in different modules whith differ arrays (for example), you may see in debugger different sizes of arrays whith one name in different modules, and what about commons?
And another one bug, if you type in watch common name whith leading _, debugger show strange value (first item in common in hexadecimal form), and where this symbol in source code?
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page