We have dups in global / file static variables definition:
- between compiland stream and global (DBI) stream
(we need to de-dup these)
- still adding variables only present global DBI stream
- keeping in mind, we need to keep:
+ two variables of different names at same address (aliasing)
+ variables of same name at different addresses
(MS linker generate those)
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Only load records that are listed in global hash file when handling
the global symbol stream.
Do the same thing for the public symbols.
When using MS linker in incremental mode:
- old variable definitions are kept in the (DBI) global symbol stream
along side the new definition
- but only the latest (valid) definition is referenced from the hash
table
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Change strategy for resetting local scope when unloading a module.
Old strategy was keeping the local scoped symbol alive on some code path when
unloading a module.
This caused some bad behavior as we kept a pointer to a deleted object.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
When using an inline context which depth points towards the top level function
(so when it's not strictly speaking an inline context), native falls
back to picking information in the top level function.
So we do now in SymSetScopeFromInlineContext() and SymFromInlineContext()
(instead of returning an error).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
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>
Fixes a crash when starting kernrate.exe.
Signed-off-by: Thomas Faber <thomas.faber@reactos.org>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Dwarf4 clarified that only FORM_sec_offset can refer to location
lists, fix dwarf2_compute_location_attr accordingly.
This fixes the 'fixme:dwarf2_parse_udt_member: Found register, while
not expecting it' messages.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
They shouldn't fail if passed address is inside a module, even if it
doesn't point to a function.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
gcc can emit functions with code spread across non contiguous code areas.
We used to register those functions with an address range enclosing all ranges
(meaning that all addresses not actually belonging to the function but
lying in that address range could be returned by dbghelp as belonging
to the function).
Work around this by registering the function with only the first range
of addresses (this will avoid the errors described above), but will
fail to mark the other address ranges as part of the function.
dbghelp doesn't seem to have explicit support of those cases, even if
pdb/codeview also support functions with multi range of addresses
(see S_SEPCODE).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Use it to reimplement dwarf2_feed_inlined_ranges.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Old version of PDB files can have a stream #4 which is not an IPI stream
Available documentation isn't 100% clear about when IPI has been
introduced.
So decide that IPI is present when header of stream looks like a type
stream header.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Requires to join DEBUG_S_INLINEES subsection with symbol annotations.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This fixes a couple of wrong pointer size computation when debugging a
WoW64 process from a 64 bit debugger.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This happens (at least) in dwarf debug info where there could be two entries
with same source file and line number, but different column numbers
(and we don't store columns).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It used to be an offset to the start of function, but it's actually
stored as an absolute address afterwards. This avoids unnecessary
computations.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of passing it as a parameter in various subprogram related
functions.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
- make SymSetContext() generate this information
- let SymEnumSymboli() (when dealing with local symbols) use this
information instead of the stack frame
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Also move SymSetScopeFromAddr out of symbol.c into dbghelp.c which
makes more sense as modification of process settings.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
