FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

I found bugs in cv2pdb

 
Post new topic   Reply to topic     Forum Index -> cv2pdb
View previous topic :: View next topic  
Author Message
Z3N



Joined: 13 Jul 2010
Posts: 4
PostPosted: Tue Jul 13, 2010 5:08 am    Post subject: I found bugs in cv2pdb Reply with quote
Hello!
I'am write pdb files generation for FASM (assembly language). Thanks for you sources! You do great work! But you code contain errors Sad. I'am spend one day for search bugs.

You calculation of AddressOfRawData totally wrong! Visual Studio can load you pdb files, but other debuggers can't. VS is too loyal to you Wink, but others debuggers not! VS load correspond pdb file not from exe's debug dir record. She search pdb file named as exe in working directory. If you copy exe in other directory and start debug in this directory all debuggers fail (VS, too).

In our case the AddressOfRawData equal VirtualAddress, because we write in beginning of section. Code below is right only in this case.

Code:
dbgDir->PointerToRawData = sec[s].PointerToRawData;
dbgDir->AddressOfRawData = sec[s].VirtualAddress;


After this little fix all debuggers loas pdb correctly!


And you calculate wrong "size of data". In all exe's what I see she == sizeof(OMFSignatureRSDS) (and also including terminating null). But, you put size of whole section. In you case, when we create section, we know, what size of section should be (OMFSignatureRSDS+IMAGE_DEBUG_DIRECTORY). You can simply calculate "size of data":

Code:
dbgDir->SizeOfData = sec[s].SizeOfRawData-sizeof(IMAGE_DEBUG_DIRECTORY);


Or you can rewrite entire proc Wink

And you not generate full path for source files. I mean only main source file (like cvtest.d in you test project). You can see it, just run "Dia2Dump.exe -all cvtest.exe>notlol.txt" (Dia2Dump.exe you can find in VS folder). Other debuggers can't find cvtest.d because he don't now anything about "src" folder. VS, can find, because src folder included in shes environment.

I'm use version 13.

Tell me, please what docs you read about pdb format?

Thx, bye!
Back to top
View user's profile Send private message
sagitario



Joined: 03 Mar 2007
Posts: 292
PostPosted: Wed Jul 14, 2010 1:51 am    Post subject: Re: I found bugs in cv2pdb Reply with quote
Hi,

Z3N wrote:
Hello!
I'am write pdb files generation for FASM (assembly language). Thanks for you sources! You do great work! But you code contain errors Sad. I'am spend one day for search bugs.


I guess noone is immune to creating bugs. Sorry it spoiled your day.

Z3N wrote:

You calculation of AddressOfRawData totally wrong! Visual Studio can load you pdb files, but other debuggers can't. VS is too loyal to you Wink, but others debuggers not! VS load correspond pdb file not from exe's debug dir record. She search pdb file named as exe in working directory. If you copy exe in other directory and start debug in this directory all debuggers fail (VS, too).

In our case the AddressOfRawData equal VirtualAddress, because we write in beginning of section. Code below is right only in this case.

Code:
dbgDir->PointerToRawData = sec[s].PointerToRawData;
dbgDir->AddressOfRawData = sec[s].VirtualAddress;


After this little fix all debuggers loas pdb correctly!


And you calculate wrong "size of data". In all exe's what I see she == sizeof(OMFSignatureRSDS) (and also including terminating null). But, you put size of whole section. In you case, when we create section, we know, what size of section should be (OMFSignatureRSDS+IMAGE_DEBUG_DIRECTORY). You can simply calculate "size of data":

Code:
dbgDir->SizeOfData = sec[s].SizeOfRawData-sizeof(IMAGE_DEBUG_DIRECTORY);


Or you can rewrite entire proc Wink



Thanks for the fixes. The code was very much build for DMD output which has its quirks on its own, so I'll have a look if the changes do affect it.

Z3N wrote:

And you not generate full path for source files. I mean only main source file (like cvtest.d in you test project). You can see it, just run "Dia2Dump.exe -all cvtest.exe>notlol.txt" (Dia2Dump.exe you can find in VS folder). Other debuggers can't find cvtest.d because he don't now anything about "src" folder. VS, can find, because src folder included in shes environment.


cv2pdb does not touch any source files, it just converts the debug information. The path names are already missing in the output generated by DMD.

Z3N wrote:
I'm use version 13.

Tell me, please what docs you read about pdb format?


cv2pdb is the result of extracting interfaces from the debug symbols provided by microsoft for the mspdb*.dll and a lot of studying of hex dumps. I've been using Dia2Dump and a dump utility from the wine project (iirc called cvdump).

Someone else found http://undocumented.rawol.com/ (end of chapter 1) , but it seems a bit outdated with respect to debug information.

Rainer
Back to top
View user's profile Send private message
Z3N



Joined: 13 Jul 2010
Posts: 4
PostPosted: Wed Jul 14, 2010 4:38 am    Post subject: Reply with quote
Quote:
The path names are already missing in the output generated by DMD

Maybe patch DMD? Windows have the corresponding api for getting full path of file.

Thx, link useful
Back to top
View user's profile Send private message
sagitario



Joined: 03 Mar 2007
Posts: 292
PostPosted: Wed Jul 14, 2010 3:55 pm    Post subject: Reply with quote
Z3N wrote:
Quote:
The path names are already missing in the output generated by DMD

Maybe patch DMD? Windows have the corresponding api for getting full path of file.


Actually I did that patch just a few days ago (in an unsuccessful attempt to fix a problem with multiple files with identical names loaded in visual studio). I might add a bugzilla entry to dmd...
Back to top
View user's profile Send private message
Z3N



Joined: 13 Jul 2010
Posts: 4
PostPosted: Thu Jul 15, 2010 4:11 am    Post subject: Reply with quote
Quote:
in an unsuccessful attempt to fix a problem with multiple files with identical names loaded in visual studio


Just in case. You compare file handles, not full path name (in DMD)? Question

You can replace makefullpath proc with windows api GetFullPathName. This api return full path for files. GetFullPathName faster than you makefullpath.

Why are you create one global module __Globals? I see bool which switch between global and non-global mod. But this bool is "static" and change bool state we can only when you compile code. In others pdb's one module per obj.
Back to top
View user's profile Send private message
sagitario



Joined: 03 Mar 2007
Posts: 292
PostPosted: Thu Jul 15, 2010 1:29 pm    Post subject: Reply with quote
Z3N wrote:
Quote:
in an unsuccessful attempt to fix a problem with multiple files with identical names loaded in visual studio


Just in case. You compare file handles, not full path name (in DMD)? Question


I'm not sure I understand. The patch in dmd was to emit full path strings into the debug info where there were relative paths. The problem in VS is that, if there are two identically named files, VS does not always show the correct file when you are debugging through the code or are setting breakpoints.

Z3N wrote:
Why are you create one global module __Globals? I see bool which switch between global and non-global mod. But this bool is "static" and change bool state we can only when you compile code. In others pdb's one module per obj.


IIRC it is like this because there is global type and symbol information in the DMD/optlink generated executable and I did not find any other way to add it to the pdb than to put it into some pseudo module. Alternative, I tried adding the info to each module, but this did not work.
Back to top
View user's profile Send private message
Z3N



Joined: 13 Jul 2010
Posts: 4
PostPosted: Fri Jul 16, 2010 4:16 am    Post subject: Reply with quote
Quote:
I tried adding the info to each module, but this did not work


I think that you code not always right.

Code:

int rc = mod->AddLines(name, seg, segoff, seglength, segoff, lineNo[0],
                                      (unsigned char*) lineInfo, cnt * sizeof(*lineInfo));


Why are segoff occur twice? It's has no sense. After I will write the program I will try to understand with it.
Back to top
View user's profile Send private message
sagitario



Joined: 03 Mar 2007
Posts: 292
PostPosted: Sat Jul 17, 2010 12:18 am    Post subject: Reply with quote
Without any documentation of the API into mspdb*.dll at all, a lot of cv2pdb is guess work. So I would be surprised if everything is correct Wink

If I remember correctly, (seg,segoff,seglength) describe the current section of code, while (segoff,lineNo[0]) is the base for the info in the lineInfo array.
Back to top
View user's profile Send private message
sagitario



Joined: 03 Mar 2007
Posts: 292
PostPosted: Sat Jul 17, 2010 12:34 am    Post subject: Reply with quote
Quote:
Code:

dbgDir->PointerToRawData = sec[s].PointerToRawData;
dbgDir->AddressOfRawData = sec[s].VirtualAddress;


After this little fix all debuggers loas pdb correctly!


I have applied your changes. For the changelog: which debuggers are affected by this patch?

Rainer
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> cv2pdb All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group