llvm dev - Nov 2014 - [LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)

On Tue Nov 04 2014 at 12:43:05 PM Peter S. Housel <housel at acm.org>
wrote:
> On 11/04/2014 07:04 AM, Robinson, Paul wrote:
> >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Sean Silva
> >>
> >> You haven't established that you really need this. AFAIK
Apple's linker
> >> doesn't need this version information and they have shipped
LTO for a
> >> while now.
> > Does Apple support library/middleware providers shipping bitcode
instead
> > of object code?  That's the most nervous-making scenario for
> compatibility.
> > LTO by itself needs bitcode only as an ephemeral stage between source
and
> > object; it's supporting bitcode as a long-lived on-disk format
that keeps
> > us awake at night.
> >
> > I acknowledge the compatibility promise but I've been whacked
upside the
> > head too often by QA over the years to take an unverified promise at
> > face value.  I would like worked examples and industry experience
> reports.
> > --paulr
>
> I've been bitten by trying to do this sort of thing recently. The
> released LLVM 3.4 and 3.5, and the Xcode 5.x tools, generate debug info
> marked with the module flag:
>
>      !49 = metadata !{i32 2, metadata !"Debug Info Version", i32
1}
>
> The tools included with Xcode 6.x generate debug info marked as:
>
>      !49 = metadata !{i32 2, metadata !"Debug Info Version", i32
600054001}
>
>
This is an apple bug. You should report it.

> and will discard debug info marked with any other version.
>
>
This is correct behavior.

> I had originally hoped that our (Open Dylan) compiler could output
> bitcode that people could compile and link using the standard
> /usr/bin/clang installed with Xcode, but it's looking more like we may
> want to provide users with a build of vanilla LLVM/Clang for this
> platform instead.
>
> Hopefully the debug info improvements currently under way will
> incorporate a compatibility guarantee that Apple-distributed tools will
> stick to as well.
>
>
Unlikely for now though I don't speak for Apple.

-eric

> -Peter-
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/378ae035/attachment.html>

> On Nov 4, 2014, at 1:40 PM, Eric Christopher <echristo at gmail.com>
wrote:
> 
> 
> 
> On Tue Nov 04 2014 at 12:43:05 PM Peter S. Housel <housel at acm.org
<mailto:housel at acm.org>> wrote:
> On 11/04/2014 07:04 AM, Robinson, Paul wrote:
> >> From: llvmdev-bounces at cs.uiuc.edu <mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu
<mailto:llvmdev-bounces at cs.uiuc.edu>] On Behalf Of Sean Silva
> >>
> >> You haven't established that you really need this. AFAIK
Apple's linker
> >> doesn't need this version information and they have shipped
LTO for a
> >> while now.
> > Does Apple support library/middleware providers shipping bitcode
instead
> > of object code?  That's the most nervous-making scenario for
compatibility.
> > LTO by itself needs bitcode only as an ephemeral stage between source
and
> > object; it's supporting bitcode as a long-lived on-disk format
that keeps
> > us awake at night.
> >
> > I acknowledge the compatibility promise but I've been whacked
upside the
> > head too often by QA over the years to take an unverified promise at
> > face value.  I would like worked examples and industry experience
reports.
> > --paulr
> 
> I've been bitten by trying to do this sort of thing recently. The
> released LLVM 3.4 and 3.5, and the Xcode 5.x tools, generate debug info
> marked with the module flag:
> 
>      !49 = metadata !{i32 2, metadata !"Debug Info Version", i32
1}
> 
> The tools included with Xcode 6.x generate debug info marked as:
> 
>      !49 = metadata !{i32 2, metadata !"Debug Info Version", i32
600054001}
> 
> 
> This is an apple bug. You should report it.
No, it is intentional. Because our releases are not aligned with any LLVM
release, we’re using debug version numbers that are completely different from
trunk.
>  
> and will discard debug info marked with any other version.
> 
> 
> This is correct behavior.
>  
> I had originally hoped that our (Open Dylan) compiler could output
> bitcode that people could compile and link using the standard
> /usr/bin/clang installed with Xcode, but it's looking more like we may
> want to provide users with a build of vanilla LLVM/Clang for this
> platform instead.
> 
> Hopefully the debug info improvements currently under way will
> incorporate a compatibility guarantee that Apple-distributed tools will
> stick to as well.
> 
> 
> Unlikely for now though I don't speak for Apple.
We would love to have our debug info be compatible with the open-source version.
We would need a stable representation of debug info for that to be possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/4a36273f/attachment.html>

>
>
> This is an apple bug. You should report it.
>
>
> No, it is intentional. Because our releases are not aligned with any LLVM
> release, we’re using debug version numbers that are completely different
> from trunk.
>
>
I'm talking to adrian about it. It's still a bug IMO, but it's up to
you
how you want to version anything in your releases.

>
> Unlikely for now though I don't speak for Apple.
>
>
> We would love to have our debug info be compatible with the open-source
> version. We would need a stable representation of debug info for that to be
> possible.
>
I disagree, but I'm also unwilling to debate it any further as I don't
have
time.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/93e84cab/attachment.html>

> On Nov 4, 2014, at 1:40 PM, Eric Christopher <echristo at gmail.com>
wrote:
> 
> 
> 
> On Tue Nov 04 2014 at 12:43:05 PM Peter S. Housel <housel at acm.org
<mailto:housel at acm.org>> wrote:
> On 11/04/2014 07:04 AM, Robinson, Paul wrote:
> >> From: llvmdev-bounces at cs.uiuc.edu <mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu
<mailto:llvmdev-bounces at cs.uiuc.edu>] On Behalf Of Sean Silva
> >>
> >> You haven't established that you really need this. AFAIK
Apple's linker
> >> doesn't need this version information and they have shipped
LTO for a
> >> while now.
> > Does Apple support library/middleware providers shipping bitcode
instead
> > of object code?  That's the most nervous-making scenario for
compatibility.
> > LTO by itself needs bitcode only as an ephemeral stage between source
and
> > object; it's supporting bitcode as a long-lived on-disk format
that keeps
> > us awake at night.
> >
> > I acknowledge the compatibility promise but I've been whacked
upside the
> > head too often by QA over the years to take an unverified promise at
> > face value.  I would like worked examples and industry experience
reports.
> > --paulr
> 
> I've been bitten by trying to do this sort of thing recently. The
> released LLVM 3.4 and 3.5, and the Xcode 5.x tools, generate debug info
> marked with the module flag:
> 
>      !49 = metadata !{i32 2, metadata !"Debug Info Version", i32
1}
> 
> The tools included with Xcode 6.x generate debug info marked as:
> 
>      !49 = metadata !{i32 2, metadata !"Debug Info Version", i32
600054001}
Apple clang uses a Debug Info Version that is derived from the clang version
number (600.54.1 in this case). Apple clang’s release cycle is decoupled from
the LLVM release cycle, so it is intentionally using a completely different
range for the Debug Info Version number.

-- adrian
> 
> 
> This is an apple bug. You should report it.
>  
> and will discard debug info marked with any other version.
> 
> 
> This is correct behavior.
>  
> I had originally hoped that our (Open Dylan) compiler could output
> bitcode that people could compile and link using the standard
> /usr/bin/clang installed with Xcode, but it's looking more like we may
> want to provide users with a build of vanilla LLVM/Clang for this
> platform instead.
> 
> Hopefully the debug info improvements currently under way will
> incorporate a compatibility guarantee that Apple-distributed tools will
> stick to as well.
> 
> 
> Unlikely for now though I don't speak for Apple.
> 
> -eric
>  
> -Peter-
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/a9c023a9/attachment.html>