Re: cygport may not create debug info if top directory contains a symlink

[Christian Franke <Christian.Franke@t-online.de>]

Jon Turney wrote:
> On 20/09/2023 11:58, Christian Franke via Cygwin-apps wrote:
>> Brian Inglis wrote:
>>> On 2023-09-18 04:41, Christian Franke via Cygwin-apps wrote:
>>>> Brian Inglis wrote:
>>>>> On 2023-09-17 08:01, Jon Turney via Cygwin-apps wrote:
>>>>>> On 16/09/2023 15:17, Christian Franke via Cygwin wrote:
>>>>>>> Found during tests of busybox package:
>>>>>>> If the path of the top build directory contains a symlink and 
>>>>>>> the project's build scripts normalize pathnames, no debug info 
>>>>>>> is created by cygport.
>>>>>>>
>>>>>>> This is because options like
>>>>>>>   -fdebug-prefix-map=${B}=/usr/src/debug/${PF}
>>>>>>> have no effect because ${B} contains a symlink but the compiler 
>>>>>>> is run with the real source path.
>>>>>>
>>>>>> I think that there was some historical bug with gcc where a 
>>>>>> relative path for the old path in this mapping wasn't correctly 
>>>>>> handled, which is why were using an absolute path here at all.
>>>>>>
>>>>>> So changing it to something like [1] (if that works), might be 
>>>>>> better.
>>>>>>
>>>>>> [1] 
>>>>>> https://github.com/jon-turney/cygport/commit/4175d456a9184c5cdebd8bfb4b5ba30583cedd66
>>>
>>> Should bin/cygport.in:534: not have $B between the == as in line 531:
>>>
>>>     declare ${flags}+=" -fdebug-prefix-map=${B}=/usr/src/debug/${PF}"
>>>     ...
>>>     declare ${flags}+=" -fdebug-prefix-map==/usr/src/debug/${PF}"
>>>
>>> or be hoist above the condition if identical, unless that is some 
>>> undocumented default for cwd?
>>
>> I guess the == without ${B} is intentional because it makes the debug 
>> source path relative to ${B} as lines 535-536 also do.
>
> Yeah, I think that "==" is shorthand for "=.=", i.e. relative to cwd.
>

Further tests show that "==" behaves strange and is not useful at all 
(no problem as it doesn't actually appear in cygport.in).

The "=.=" only does a simple replacement of first "." in source name.

Testcases with file.c in /var/tmp/test:

$ gcc -g file.c && objdump -dl a.exe | grep -F file.c
/var/tmp/test/file.c:1

$ gcc -g ./file.c && objdump -dl a.exe | grep -F file.c
/var/tmp/test/./file.c:1

$ gcc -g ../test/file.c && objdump -dl a.exe | grep -F file.c
/var/tmp/test/../test/file.c:1

$ gcc -g -fdebug-prefix-map==/foo/bar file.c && ...
/foo/bar/foo/barfile.c:1

$ gcc -g -fdebug-prefix-map=.=/foo/bar file.c && ...
/var/tmp/test/file.c:1

$ gcc -g -fdebug-prefix-map=.=/foo/bar ./file.c && ...
/foo/bar/file.c:1

$ gcc -g -fdebug-prefix-map=/var/tmp/test=/foo/bar file.c && ...
/foo/bar/file.c:1

Source directories with symlinks are preserved in line number info like 
with 'pwd -L'.


> Does using relative paths in the prefix-map resolve the original issue 
> seen with busybox?

No, relative paths do not work. Adding this to top of src_compile() works:

    CFLAGS+=" -fdebug-prefix-map=$(cd ${S} && pwd -P)=/usr/src/debug/${PF}"

Same for ${B} is not required for this project. This also works (B and S 
are not set yet):

  DEBUG_PREFIX_MAPS=( "$(pwd -P)/${PF}.${ARCH}/src/${PN}-${PV}" )


> (It's unclear to me how gcc compares paths to apply this mapping. If 
> it's a literal string prefix, rather than on some (semi-)canonicalized 
> path, then we're maybe going to lose here sometimes, depending on the 
> vagaries of the build-system, unless we list all of relative, 
> absolute, and canonical absolute paths?)
>
> (But then maybe we can push dealing with or indicating which of those 
> is correct off onto the individual cygport?)
>

Adding this if "$(cd ${S} && pwd -P)" != "${S}" should IMO be safe:
   -fdebug-prefix-map=$(cd ${B} && pwd -P)=/usr/src/debug/${PF}
   -fdebug-prefix-map=$(cd ${S} && pwd -P)=/usr/src/debug/${PF}
(or use realpath)