[LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)

Eric Christopher echristo at gmail.com
Tue Nov 4 13:40:19 PST 2014


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>


More information about the llvm-dev mailing list