Reading raw debug symbol data

[ecube]

yeah I meant it worked without adjusting anything, I suppose I should just use the macro :)

[ecube]

beatrix your lib is weird, it doesnt display the instructions string correctly :\ idk why. you mind recompiling the latest versions or giving directions on how to?

Update I just compiled to a lib myself using visual studio 6.0 and its definitely not outputting correct strings :( is missings mov, jmp etc... some strings are even empty,ugh.

[donkey]

Hi E^cube,

Could you post an example project and detail the lines that have problems, I have used the lib in GoP but now I'm worried that the disassembly might have problems.

Edgar

[ecube]

Donkey,

here's an example of the latest lib that I compiled myself, aswell as the old lib found before on the site(that worked). you can try beatrix's lib too, neither output the write strings.

also I don't know why it's messing up, i'll have to try and find the reason in the c code.

[donkey]

Hi E^cube,

I'm in BC for the week but should be home Sunday, I will take a look at it then.

[beatrix]

Hi E^Cube,

I think it is only a problem of compiler. Last version of BeaEngine are compiled with gcc and GoAsm can't use these versions. Just try to use the lib in the joined archive, it works fine.

[ecube]

Hi E^Cube,

I think it is only a problem of compiler. Last version of BeaEngine are compiled with gcc and GoAsm can't use these versions. Just try to use the lib in the joined archive, it works fine.

Thanks beatrix, I appreciate all the hardwork you've put into BeaEngine, it really is amazing. Even more amazing is the license, most people just use regular GPL which makes their project completely useless to me, you on the other hand took the more intelligent, considerate route. I commend you. I hope you consider putting up a donation button on your site  :thumbu

[brixton]

Hi all,

I don't know if you've found this, but with different linkers comes different symbol table usage.  For instance, my main gripe is with Cygwin's GCC (may be the same in the original GCC) where the 'Value' field of an IMAGE_SYMBOL structure does not seem to give a value which is an offset from the image base, but rather from the start of a data section (ie. a value of 0x20 rather than something in the thousands).  This is confusing my symbol table parser and I cannot see an obvious way around it..

Tom

[ecube]

Hi all,

I don't know if you've found this, but with different linkers comes different symbol table usage.  For instance, my main gripe is with Cygwin's GCC (may be the same in the original GCC) where the 'Value' field of an IMAGE_SYMBOL structure does not seem to give a value which is an offset from the image base, but rather from the start of a data section (ie. a value of 0x20 rather than something in the thousands).  This is confusing my symbol table parser and I cannot see an obvious way around it..

Tom

OffsetToRva function should fix that.

[brixton]

Hi all,

I don't know if you've found this, but with different linkers comes different symbol table usage.  For instance, my main gripe is with Cygwin's GCC (may be the same in the original GCC) where the 'Value' field of an IMAGE_SYMBOL structure does not seem to give a value which is an offset from the image base, but rather from the start of a data section (ie. a value of 0x20 rather than something in the thousands).  This is confusing my symbol table parser and I cannot see an obvious way around it..

Tom

OffsetToRva function should fix that.

Hi E^cube,

Where is this function?

[donkey]

Hi Brixton,

Not sure about the OffsetToRva function, but there are many DbgHelp functions and I find ImageNtHeader / ImageRvaToVa very useful when reading PE files. I think its what you're looking for but if you need to go in the other direction SymFromAddr works just fine as well but requires a bit more setup.

http://msdn.microsoft.com/en-us/library/ms679291%28v=VS.85%29.aspx

This code is in GoAsm format and will enumerate symbols but it demonstrates how to use the symbol table and the Sym... functions:

Code Select Expand

EnumerateSymbols FRAME hFile, hProcess, ImageBase
LOCAL fsh:%DWORD32
LOCAL fsl:%DWORD32
LOCAL ProcessPath[2048]:%CHAR
LOCAL ihmod64:IMAGEHLP_MODULE64

mov D[ProcessPath],0

invoke SetLastError,0
invoke GetProcessImageFileName ,[hProcess],offset ProcessPath,MAX_PATH

invoke GetFileSize,[hFile],offset fsh
mov [fsl],eax

invoke SymInitialize,[hProcess], offset ProcessPath, FALSE

invoke SymLoadModuleEx,[hProcess],[hFile],offset ProcessPath,NULL,[ImageBase],0,[fsl],0,0

push eax,edx

mov D[ihmod64.SizeOfStruct],SIZEOF IMAGEHLP_MODULE64
invoke SymGetModuleInfo64,[hProcess],[ImageBase],0,offset ihmod64

cmp D[ihmod64.SymType],SymNone
je >>.NOSYMBOLS

pop edx,eax
invoke SymEnumSymbols,[hProcess],eax,edx,"*",offset SymEnumSymbolsProc, [hProcess]

invoke SymUnloadModule64,[hProcess],[ImageBase],0

invoke SymCleanup,[hProcess]
xor eax,eax
RET

.NOSYMBOLS
xor eax,eax
dec eax
ret
ENDF

SymEnumSymbolsProc FRAME pSymInfo, SymbolSize, UserContext

...

.CONTINUE
mov eax,TRUE
RET
ENDF

[brixton]

Hi donkey,

Thanks a lot for the reply, I will bare this in mind (and perhaps implement it, if I have time.. the deadline is fast approaching).  Yesterday I found the cause of the problem:  the .bss section:

... the bss section typically includes all uninitialized variables declared at the file level (i.e., outside of any function) as well as uninitialized local variables declared with the static keyword. An implementation may also assign statically-allocated variables initialized with a value consisting solely of zero-valued bits to the bss section.

Hence, all of the global variables were actually present at (symbol table.Value+ImageBase+offset of .bss section) - this was found with some detective work and olly.

Tom

[ecube]

Donkey why did you use %DWORD32? according to your definition it's just a structure defined as DD which doesn't change depending on 34bit or 64bit? %INT_PTR appears to change though. Also here are some mov/cmp macros you can use for 32bit/64bit to auto convert.

Code Select Expand


%MOV(%DESTN,%SOURCE) MACRO
#IFNDEF WIN64
mov D[%DESTN],%SOURCE
#ELSE
mov Q[%DESTN],%SOURCE
#ENDIF
ENDM

%CMP(%DESTN,%SOURCE) MACRO
#IFNDEF WIN64
cmp D[%DESTN],%SOURCE
#ELSE
cmp Q[%DESTN],%SOURCE
#ENDIF
ENDM


Code Select Expand



%MOV(myvar,53)
%CMP(myvar,54)
jne >


[donkey]

Hi E^cube,

It is a very early draft and I never noticed, nothing more sinister than that :) But I believe that file size high (fsh) and file size low (fsl) remain DWORDs even when in 64 bit mode:

Code Select Expand

DWORD WINAPI GetFileSize(
  __in       HANDLE hFile,
  __out_opt  LPDWORD lpFileSizeHigh
);


Edgar