DbgHelp: Fix for Includes with Relative Paths
Robert Shearman
rob at codeweavers.com
Mon Aug 23 14:39:29 CDT 2004
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 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.
>>
> Robert, normally currpath is supposed to be the directory where the
> file has been compiled. So, IMO currpath and srcpath duplicate the
> same stuff.
>
> 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).
[dm at rob 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:
[dm at rob 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
More information about the wine-devel
mailing list