llvm dev - Nov 2018 - DIFile filenames containing directories

Can't say I know much about -fdebug-prefix-map, but...

On Thu, Nov 29, 2018 at 1:07 PM Adrian Prantl <aprantl at apple.com>
wrote:
> Thanks for the feedback! Closely-related follow-up question: Is *this* a
> bug?
>
> llvm/tools/clang/test/CodeGen/debug-prefix-map.c:33:27:
> // CHECK-COMPILATION-DIR: !DIFile(filename:
> "/var/empty{{[/\\]}}Inputs/stdio.h", directory:
"/var/empty")
>
Yeah, that doesn't look quite right to me. The duplication of the directory
in both the filename and directory...

Well, I guess it could be read as "resolve the filename relative to this
directory" - but since the filename is absolute, the directory is ignored?

>
> -- adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181129/438a77eb/attachment.html>

> On Nov 29, 2018, at 1:19 PM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> Can't say I know much about -fdebug-prefix-map, but...
> 
> On Thu, Nov 29, 2018 at 1:07 PM Adrian Prantl <aprantl at apple.com
<mailto:aprantl at apple.com>> wrote:
> Thanks for the feedback! Closely-related follow-up question: Is *this* a
bug?
> 
> llvm/tools/clang/test/CodeGen/debug-prefix-map.c:33:27:
> // CHECK-COMPILATION-DIR: !DIFile(filename:
"/var/empty{{[/\\]}}Inputs/stdio.h", directory:
"/var/empty")
> 
> Yeah, that doesn't look quite right to me. The duplication of the
directory in both the filename and directory...
> 
> Well, I guess it could be read as "resolve the filename relative to
this directory" - but since the filename is absolute, the directory is
ignored?
>  
Apparently LLVM is smart enough to not emit this as
"/var/empty/var/empty/...", but I don't understand why we
wouldn't strip the directory prefix in CGDebugInfo::getOrCreateFile() to
save space, or at least not emit a redundant directory.

I'll send out a patch to strip a common prefix. It should save a little bit
of memory and go better with my sense of aesthetics :-)

Let me know if someone has an idea why this would be useful to keep.

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181129/12d0f52f/attachment.html>

Try compiling -S before you say LLVM is that smart... like I said, the
.debug-line header comes out differently.
In which case this would be a real bug and not just aesthetic.
--paulr

From: aprantl at apple.com [mailto:aprantl at apple.com]
Sent: Thursday, November 29, 2018 4:21 PM
To: David Blaikie
Cc: Robinson, Paul; llvm-dev; Davide Italiano
Subject: Re: DIFile filenames containing directories




On Nov 29, 2018, at 1:19 PM, David Blaikie <dblaikie at
gmail.com<mailto:dblaikie at gmail.com>> wrote:

Can't say I know much about -fdebug-prefix-map, but...
On Thu, Nov 29, 2018 at 1:07 PM Adrian Prantl <aprantl at
apple.com<mailto:aprantl at apple.com>> wrote:
Thanks for the feedback! Closely-related follow-up question: Is *this* a bug?

llvm/tools/clang/test/CodeGen/debug-prefix-map.c:33:27:
// CHECK-COMPILATION-DIR: !DIFile(filename:
"/var/empty{{[/\\]}}Inputs/stdio.h", directory:
"/var/empty")

Yeah, that doesn't look quite right to me. The duplication of the directory
in both the filename and directory...

Well, I guess it could be read as "resolve the filename relative to this
directory" - but since the filename is absolute, the directory is ignored?


Apparently LLVM is smart enough to not emit this as
"/var/empty/var/empty/...", but I don't understand why we
wouldn't strip the directory prefix in CGDebugInfo::getOrCreateFile() to
save space, or at least not emit a redundant directory.

I'll send out a patch to strip a common prefix. It should save a little bit
of memory and go better with my sense of aesthetics :-)

Let me know if someone has an idea why this would be useful to keep.

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181129/8851a8e1/attachment.html>