similar to: Adding bitcode to an existing MachO object file

We've noticed a difference in the embedded bitcode when compiling human readable IR to an object directly vs first compiling IR to BC and then an object through clang -cc1. If the original IR file contained an "llvm.compiler.used" gv, it will be preserved when compiling IR -> BC -> Obj. When compiling IR -> Obj directly, it will be removed. This difference does not exist

Apple has some internal implemenation for embedding bitcode in the object file that we would like to upstream. It has few changes to clang frontend, including new clang options, clang driver changes and utilities to embed bitcode inside object file. We believe upstreaming these implementations will benefit the people who would like to develop software on Apple platform using open source LLVM. It

Going from IR <-> BC does not seem to create a difference. IR -> BC -> IR -> BC, either with clang frontent or by using llvm-as and llvm-dis yields identical bc files. I have only been able to reproduce this issue when emitting to an object file. > On 18 Jan 2019, at 18:09, <paul.robinson at sony.com> <paul.robinson at sony.com> wrote: > > > >>

Hi Peter It is not currently related because we started the implementation before Thin-LTO gets proposed in the community but our "__LLVM, __bitcode" section is pretty much the same as ".llvmbc" section. Note ".llvmbc" doesn't really follow the section naming convention for MachO objects. I am hoping to unify them during the upstream of the implementation.

Hi everyone I am still in the process of upstreaming some improvements to the embed bitcode option. If you want more background, you can read the previous RFC (http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html <http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html>). This is part II of the discussion. Current Status: A basic version of -fembed-bitcode option

I have 2 .cpp files in two different directories in which I need to put DTrace probes. They are compiled into two .a libraries one after another. In the end they are combined to a single .so file. This sequence I can not change. I get an error "ld: fatal: symbol `__SUNW_dof'' is multiply-defined:". What is the solution for this? Here is my simulation of real world problem in

Hi Jack, Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not C++ safe. I needed to wrap my include via: #ifdef HAVE_LIBXAR extern "C" { #include <xar/xar.h> } #endif I think we may need some help from Chris to track this down. I’ll bug him in a bit to see if he can help us on this. Kev > On May 24, 2016, at

On Tue, May 24, 2016 at 1:35 PM, Kevin Enderby <enderby at apple.com> wrote: > Hi Jack, > > Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not C++ safe. I needed to wrap my include via: > > #ifdef HAVE_LIBXAR > extern "C" { > #include <xar/xar.h> > } > #endif > > I think we

Jack, What version of CMake are you using? -Chris > On May 24, 2016, at 11:00 AM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > > On Tue, May 24, 2016 at 1:35 PM, Kevin Enderby <enderby at apple.com> wrote: >> Hi Jack, >> >> Just a guess here, this may be the bug Chris helped me out with in the use of the include file xar/xar.h which is not

Thanks for the feedback! Replies inline. > On Jun 12, 2016, at 11:44 PM, Eric Christopher <echristo at gmail.com> wrote: > > Hi Steven, > > Great to see the commentary and updates here. I've got a few questions about some of this work. It might be nice to see some separate RFCs for a couple of things, but we'll figure that out after you send out patches probably :)

> On Feb 5, 2016, at 2:14 PM, James Y Knight <jyknight at google.com> wrote: > > On Wed, Feb 3, 2016 at 1:25 PM, Steven Wu via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > "__LLVM, __cmdline" is used to store the clang command-line options. There are > few options that are not reflected in the bitcode that we would

On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: > Jack, > > What version of CMake are you using? > > -Chris Chris, I am using cmake 3.5.2. My read of this problem is as follows. While libLLVM.dylib is being linked against -lxar when -DLLVM_LINK_LLVM_DYLIB:BOOL=ON is passed to cmake, the libLLVM.dylib is created with -Wl,-dead_strip such that

On Tue, May 24, 2016 at 2:37 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >> Jack, >> >> What version of CMake are you using? >> >> -Chris > > Chris, > I am using cmake 3.5.2. My read of this problem is as follows. > While libLLVM.dylib is

On Tue, May 24, 2016 at 3:03 PM, Jack Howarth <howarth.mailing.lists at gmail.com> wrote: > On Tue, May 24, 2016 at 2:37 PM, Jack Howarth > <howarth.mailing.lists at gmail.com> wrote: >> On Tue, May 24, 2016 at 2:28 PM, Chris Bieneman <beanz at apple.com> wrote: >>> Jack, >>> >>> What version of CMake are you using? >>> >>>

Hi, On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote: > > The second approach is to *not* cache modules but re-read them from disk > > (or memory, but that's irrelevant here). That works without any sort of > > asserts, but "leaks" memory because everytime a module is re-read from > > disk it re-creates types (cf

Suppose that I have the following list of lists of frames 'root' (let's call it a 'tree' of frames). I want to flatten it to be a list of frames. However, if I unlist(root), it will flatten the frames as well. Is there a simply way to flatten the tree to certain depth? aframe1=data.frame(x=1:3,y=1:3) aframe2=data.frame(u=7:9,v=11:13) aframe3=data.frame(p=3:5,q=6:8)

> On Mar 26, 2018, at 17:09, Andres Freund <andres at anarazel.de> wrote: > > Hi, > > On 2018-03-26 16:44:05 -0700, Duncan P. N. Exon Smith wrote: >>> The second approach is to *not* cache modules but re-read them from disk >>> (or memory, but that's irrelevant here). That works without any sort of >>> asserts, but "leaks" memory

You should probably pull in some folks who implemented/maintain the feature for Darwin. I guess they aren't linking this info, but only communicating in the object file between tools - maybe they flag these sections (either in the object, or by the linker) as ignored/dropped during linking. That semantic could be implemented in ELF too by marking the sections SHF_IGNORED or something

Thanks for your response! On 30/01/2019 20:18, Rui Ueyama wrote: > Hi Josef, > > Let me clarify my understanding. Do you want to keep original bitcode > files in the output executable when doing LTO, so that the resulting > executable contains both compiled bitcode (which is in native machine > instructions) and original bitcode files? Exactly! Kind of analogous to what

In the Agile WD book it states regarding sesion data- "Rails uses the cookie-based approach". This can''t be entirely true can it ? Not that I''m complaining if it was but isn''t there some equivalent to say, PHP sessions ? Or am I wrong. Stuart -------------- next part -------------- An HTML attachment was scrubbed... URL: