Dwarf4 (and GNU extensions) support following debug info in
a) different CU
b) different ELF/PE files
So add a field from debug_info into the parent context unit
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
- first phase just parse the header and do elementary checks
- second phase, actually load all DIEs in CU
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Move out of dwarf2_parse_context_s structure information related to the
module and put them into the dwarf2_parse_module_context_s structure
(actually the dwarf2_parse_context should be named dwarf2_parse_cu_context
as it only related to a compilation unit).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
And return failure when encoutering them, as they are not supported yet.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This was generating a global symbol instead of a local symbol.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Removed word_size from traverse context and make use of cuhead_t's
equivalent field instead
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Store cu information for dwarf content
- in each compiland
- and queue the unique one's inside the module.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is a temporary feature while implementing the required bits for Dwarf3
and Dwarf4 format.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
the rationale is that:
- the file name in IMAGEHLP_LINE* structures is returned as a pointer to
an internal buffer
- in the W64 variant of APIs, two calls to fetch_buffer() are currently needed
(one for first A allocation, second for W conversion)
- this generate bugs as it's assumed the two buffers are different
so the internal_line_t purpose is to factorize the implementations
of the 3 variants (A32, A64, W64) into a single code path
this insures a unique allocation, and at most, one conversion
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(modulename is truncated at 64 chars, while module.ModuleName at 32 chars)
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The former is truncated to 64 chars while the latter is truncated to
32 chars.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
use case, in a WoW setup:
wine programs/winedbg/winedbg.exe.so notepad.exe
where both winedbg and notepad are 64bit exec:s
in this case, dbghelp (loaded from winedbg) reads '<...>/wine' from WINELOADER
windows env block inside notepad
(but the unix env block is correctly set to wine64 by the tweak in
ntdll/unix/loader.c)
as a consequence dbghelp doesn't get the ELF information (it tries to read 32bit
ELF entities, and fails); hence misses all the loaded ELF libraries
winedbg's command 'info share' only reports the PE modules
note: the 'dual' case
wine64 programs/winedbg/winedbg.exe.so c:\\windows\\syswow64\\notepad.exe
where winedbg is a 64bit exec and notepad a 32bit
shows the same failures
workaround this in dbghelp by tweaking the value of WINELOADER whether
the debuggee is 32 or 64bit
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Since with the unknown type entry, we can end up with types which don't
match the expected symt->tag, we need to check before the conversions.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Eric Pouech