| View previous topic :: View next topic |
| Author |
Message |
Trass3r
Joined: 29 Feb 2008
Posts: 66
Location: Germany
|
 Posted: Fri Mar 12, 2010 5:10 pm Post subject: Future directions? |
 |
|
Any plans for the next releases?  |
|
| Back to top |
|
 |
sagitario
Joined: 03 Mar 2007
Posts: 292
|
| Posted: Sun Mar 14, 2010 4:17 pm Post subject: |
|
|
| Nothing spectacular in the queue. You can find a few changes in the subversion repository, but nothing that made me publish a new version yet. |
|
| Back to top |
|
|
Trass3r
Joined: 29 Feb 2008
Posts: 66
Location: Germany
|
| Posted: Fri Jun 04, 2010 4:53 am Post subject: |
|
|
By the way, I recently discovered that the autoexp snippet might to influence normal C++ debugging.
I debugged dmd and it showed a StorageClass which is some int64 or something like that IIRC as a dynamic int[] array.
Is this caused by your additions? Is it fixable? |
|
| Back to top |
|
|
sagitario
Joined: 03 Mar 2007
Posts: 292
|
| Posted: Fri Jun 04, 2010 5:12 am Post subject: |
|
|
The autoexp snippets do not modify the displayed type, only the value.
But I can explain it if this is for DMC generated code: the bug regarding bad codeview information for long and ulong had exactly this effect. It was in the DMD-backend, which is said to be the same as for DMC. So it is no surprise that the bad debug information also shows up for C++. |
|
| Back to top |
|
|
Trass3r
Joined: 29 Feb 2008
Posts: 66
Location: Germany
|
| Posted: Fri Jun 04, 2010 6:31 am Post subject: |
|
|
| Ah true. Well there's no way to fix that in dmc I guess. |
|
| Back to top |
|
|
sagitario
Joined: 03 Mar 2007
Posts: 292
|
| Posted: Fri Jun 04, 2010 11:21 am Post subject: |
|
|
Actually, there is a chance for cv2pdb to fix the debug info, as the passed type is a D extension, which must be invalid if -C has been passed on the command line. IIRC there was no different info for int64 and uint64, though.
Should be easy to add, so I've placed it on my todo list... |
|
| Back to top |
|
|
Trass3r
Joined: 29 Feb 2008
Posts: 66
Location: Germany
|
| Posted: Fri Jun 04, 2010 12:56 pm Post subject: |
|
|
A D extension in the dmc backend?
However, I thought about trying to compile with MinGW(in general, it should produce faster and safer code, shouldn't it?) but of course it isn't suitable for debugging purposes since the debug information produced by it can't be read by VS either 
btw: I found a book which covers the structure of .pdb files, just FYI: http://undocumented.rawol.com/ (at the end of the first chapter) |
|
| Back to top |
|
|
sagitario
Joined: 03 Mar 2007
Posts: 292
|
| Posted: Mon Jun 07, 2010 5:14 pm Post subject: |
|
|
| Quote: | | However, I thought about trying to compile with MinGW(in general, it should produce faster and safer code, shouldn't it?) but of course it isn't suitable for debugging purposes since the debug information produced by it can't be read by VS either |
With a few modifications to the dmd source, you can also build it with the microsoft compiler. But I don't know if the resulting dmd works exactly the same...
I think I have also seen this book before. Unfortunately it is a bit outdated. The debug indormation is distributed into different streams in the pdb and does not always look like oldstyle codeview information.
The wine project contains a dump utility that I have used to verify conversions by cv2pdb. But it also does not understand all the contents. |
|
| Back to top |
|
|
sagitario
Joined: 03 Mar 2007
Posts: 292
|
| Posted: Wed Jun 23, 2010 1:41 am Post subject: |
|
|
| Quote: | | Quote: | | Ah true. Well there's no way to fix that in dmc I guess. |
Should be easy to add, so I've placed it on my todo list... |
The new release 0.14 should fix the DMC types. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
