Is the attached patch correct?
yes
Eric Pouech wrote:
Robert Shearman a écrit :
How does the attached patch look?
better, but you should to nuke srcpath (and no longer currpath) in
N_SO case, when *ptr is '\0' (it's defensive code, so it shouldn't
harm on normally formed stabs file). As a side effect, you don't need
also to memse
Robert Shearman a écrit :
How does the attached patch look?
better, but you should to nuke srcpath (and no longer currpath) in N_SO
case, when *ptr is '\0' (it's defensive code, so it shouldn't harm on
normally formed stabs file). As a side effect, you don't need also to
memset currpath to 0 at
Eric Pouech wrote:
which means that:
- we create a new compilation unit (for example) on 2205 => this gives
the source directory
- we start the main compilation unit on 2206 =>
/home/dm/wine/dlls/dbghelp/elf_module.c
- in this CU, we start a new include file (on ), =>
/home/dm/wine/dlls/dbgh
which means that:
- we create a new compilation unit (for example) on 2205 => this gives
the source directory
- we start the main compilation unit on 2206 =>
/home/dm/wine/dlls/dbghelp/elf_module.c
- in this CU, we start a new include file (on ), =>
/home/dm/wine/dlls/dbghelp/../../include/w
Eric Pouech wrote:
Robert Shearman a écrit :
Hi,
On startup, the debugger usually prompted me to type the path where
"/winternl.h" can be found. This was due to the path being stored
internally as "../../include/winternl.h", i.e. relative to the source
directory. This patch adds the ability to s
Robert Shearman a écrit :
Hi,
On startup, the debugger usually prompted me to type the path where
"/winternl.h" can be found. This was due to the path being stored
internally as "../../include/winternl.h", i.e. relative to the source
directory. This patch adds the ability to store the source dir
