Global (non static) variables are now stored in symt_module.
(static variables are stored in symt_compiland).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
PDB supports description of a global or static variable:
- accessed from a register
- stored as a local variable record inside a function
This likely describes access to a global/static variable where
intermediate computation is kept in a register.
We cannot store this kind of entries in local variable lists
(builtin dbghelp and winedbg are not prepared to handle a global variable)
Note: the global or static Codeview data record is still present (with a
relocatable address), so the variable should still be available from global
access (but could be not up-to-date if temporarly stored in a register).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
The PDB hash stream from TPI header contains information to force a remap
to a given type record (whatever the order in the bucket hash list).
This is generated by the incremental linker in some occasions.
Use that information to remap the corresponding types.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
The PDB types can contain several times a type definition with an identical
name. It seems to appear when modifying a type in source (like adding new
fields to a struct):
- as the PDB file (generated from first compilation) is updated (and not
fully rewritten), the debug information for the old type is not flushed;
a new record (for the same struct name) is emitted, and inserted
before the old one in the hash table (bucket list).
Even if dbghelp's hash table is different from PDB's internal one (ie
number of buckets & bucket lists are different), we must maintain the order
of records of identical names (they end up in the same bucket) as a lookup
by name *must* return the first record in PDB's order.
Lookup by name is used:
- when resolving a forward definition (to get the full UDT definition
including for example a struct/class fields's list)
- when searching by type name from dbghelp APIs, like SymGetTypeFromName()
This patch implements the preservation of that order.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
- create (contentless) UDT & enum in first pass
- fill UDT&enum content and load the rest of types in second pass.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Code now follows these guidelines:
- define PDB & Codeview internals in cvconst.h and mscvinfo.h (instead
of having definitions in .c files, some of them being duplicate of .h
content, and their "duplicate" values eventually diverged over time)
- index of first type comes from PDB type header (instead of always being
hardcoded as FIRST_DEFINABLE_TYPE)
- use index of last typex from type header (instead of guessing the right
value while parsing types, which also allows a single allocation
instead of enlarging buffer while parsing).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Rationale:
- native doesn't report names for SymTagBaseType objects
=> so remove typename for sym_basic
- since symt_basic becomes pretty simple, it's possible to share the object
across all modules loaded in dbghelp (simplicity, memory usage reduction)
- removed dwarf basic types cache in dwarf.c as we now have a generic one
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
To be used in place of symt_find_nearest().
symt_find_symbol_at() ensures that the address passed is within the
boundaries of the returned symbol (while find_nearest() doesn't).
This fixes erroneous backtraces in debugger like:
$ ./wine winedbg notepad
WineDbg starting on pid 0104
RtlDefaultNpAcl () at Z:\home\eric\work\wine\dlls\ntdll\sec.c:1731
0x00000170054805 ntdll+0x54805 [Z:\home\eric\work\wine\dlls\ntdll\sec.c:1731]: ret
1731 }
Wine-dbg>bt
Backtrace:
=>0 0x00000170054805 RtlDefaultNpAcl+0x2d5(pAcl=<internal error>) [Z:\home\eric\work\wine\dlls\ntdll\sec.c:1731] in ntdll (0x000001700701a4)
1 0x0000017002d6c4 __wine_pop_frame(pAcl=<internal error>) [Z:\home\eric\work\wine\include\wine\exception.h:273] in ntdll (0x000001700701a4)
2 0x0000017002d6c4 process_breakpoint+0x84() [Z:\home\eric\work\wine\dlls\ntdll\loader.c:3912] in ntdll (0x000001700701a4)
3 0x000001700354c9 LdrInitializeThunk+0x509(context=<register R13 not accessible in this frame>, unknown2=<internal error>, unknown3=<internal error>, unknown4=<internal error>) [Z:\home\eric\work\wine\dlls\ntdll\loader.c:4200] in ntdll (0x000001700701a4)
where RtlDefaultNpAcl() has nothing to do here (it's the symbol below RIP
and we don't have a symbol with debug information for that address).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some internal bits of PDB files are different, so report & abort loading of
such PDB file until it's properly understood & supported (instead of
crashing).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Reading gecko's PDB generate a lot of those.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
