Frank Richter wrote:
On 26.05.2006 21:17, Eric Pouech wrote:
+/******************************************************************
SymGetSymFromAddr (DBGHELP.@)
- */
+BOOL WINAPI SymGetSymFromAddr64(HANDLE hProcess, DWORD64 Address,
PDWORD64 Displacement,PIMAGEHLP_SYMBOL64 Symbol) +{
- char buffer[sizeof(SYMBOL_INFO) + MAX_SYM_NAME];
- SYMBOL_INFO*si = (SYMBOL_INFO*)buffer;
- size_t len;
- if (Symbol->SizeOfStruct < sizeof(*Symbol)) return FALSE;
- si->SizeOfStruct = sizeof(*si);
- si->MaxNameLen = MAX_SYM_NAME;
- if (!SymFromAddr(hProcess, Address, &Displacement, si))
Also, generally, wouldn't it be more correct to call SymFromAddr from SymFromAddr64 and not vice versa? Ie forward from more limited to less limited functions, and not from less limited to more limited functions (the limitation being here that SymFromAddr() only supports 32 bit addresses etc, while SymFromAddr64() also supports 64 bit ones).
as we're only be debugging 32 bit applications (the real port to 64 bit isn't done yet), I don't think it's necessary btw, the same applies (in dbghelp) for symbols' name. they are stored as ascii strings (and I don't know of a language where identifiers are unicode, actually most of them are ascii 7 bit !!) moreovre, I do want to maintaint the overall memory consumption when loading the debug information as small as possible huge
A+