Eric Pouech wrote:
Robert Shearman a écrit :
Robert, normally currpath is supposed to be the directory where the file has been compiled. So, IMO currpath and srcpath duplicate the same stuff.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 directory and then use it when encountering an include path of this type to get the full path, which means no more prompting.
Rob
Changelog:
Store the current source directory and use it when encountering a relative include so that the full path to it is stored instead.
Does it mean that you only get one N_SO per compilation unit ? (the code assumes two: the first one for the dir, the second for the path).
[EMAIL PROTECTED] dm]$ objdump -G /usr/local/lib/wine/dbghelp.dll.so | grep " SO " | more
0 SO 0 0 00015d9c 11 /home/dm/wine/dlls/dbghelp/ 1 SO 0 0 00015d9c 1 dbghelp.c 2204 SO 0 0 000163b9 0 2205 SO 0 0 000163bc 11 /home/dm/wine/dlls/dbghelp/ 2206 SO 0 0 000163bc 166272 elf_module.c 4978 SO 0 0 00017c24 0 4979 SO 0 0 00017c24 11 /home/dm/wine/dlls/dbghelp/ 4980 SO 0 0 00017c24 346388 image.c 6782 SO 0 0 00017cf6 0 ...
The real problem is the N_SOL entries, which is what the patch fixes:
[EMAIL PROTECTED] dm]$ objdump -G /usr/local/lib/wine/dbghelp.dll.so | grep " SOL " | more
1917 SOL 0 0 00015ddf 35504 ../../include/winbase.h
1934 SOL 0 0 00015dec 1 dbghelp.c
1941 SOL 0 0 00015e16 35504 ../../include/winbase.h
1946 SOL 0 0 00015e56 1 dbghelp.c
2013 SOL 0 0 00015fc6 35504 ../../include/winbase.h
2016 SOL 0 0 00015fda 1 dbghelp.c
2020 SOL 0 0 00015ff1 35504 ../../include/winbase.h
2023 SOL 0 0 00016020 1 dbghelp.c
...
Rob
