Thomas Weidenmueller wrote:
The attached patch implements SymGetSymFromAddr64, called by steam.
a couple of coments:
@@ -996,7 +996,8 @@ sym = pair.effective->addr_sorttab[idx];
symt_fill_sym_info(&pair, &sym->symt, Symbol);
- *Displacement = Address - Symbol->Address;
- if (Displacement)
return TRUE;*Displacement = Address - Symbol->Address;
}
why do you need this ?
@@ -1053,6 +1054,31 @@ return TRUE; }
+/******************************************************************
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))
- you should test that Address can be casted down to a 32 bit entity (see other functions for how to do it) - &Displacement looks pretty wrong: you need a local 32 bit dword, pass its address, and then convert the local 32 bit value into the 64 bit pointer (Displacement)
return FALSE;
- Symbol->Address = si->Address;
- Symbol->Size = si->Size;
- Symbol->Flags = si->Flags;
- len = min(Symbol->MaxNameLength, si->MaxNameLen);
- lstrcpynA(Symbol->Name, si->Name, len);
- return TRUE;
+}
static BOOL find_name(struct process* pcs, struct module* module, const char* name, SYMBOL_INFO* symbol) {
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).
-f.r.
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+