similar to: Enabling bitcode for iOS

Pavel Punsky <Pavel.Punsky at oovoo.com> wrote: > What is the proper way of enabling bitcode on iOS platform? > I pass -fembed-bitcode in CFLAGS but it looks like it does not work > on assembly files. You cannot use bitcode with assembly. It may be possible if someone manually translates the asm into LLVM IR and then figures out how to embed it directly in a .S file, but

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

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

> 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

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

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.

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: > > > >>

I don't know whether this is an issue in the current implementation, but I wanted to bring up a potential privacy issue. In embedding the information, care should be taken to avoid embedding any information that contains personally identifiable information. This can certainly occur if paths need to be embedded, as user names, or other private/confidential information may be present in the

This is a silly question, but I am in a situation where I need to build x86 and arm assembly sources for some sources while the rest will be built with C. I do know that just adding `-fembed-bitcode` to a C sources would embed bitcode, but doing the same for the assembly files will not do that (at least, it will add the 1-byte `_LLVM,__asm` section, but not the `__LLVM,__bitcode` section).

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 :)

Sorry for probably obvious question but I could not find and answer on mail archive. What would happen to decoded audio quality if the packets fed to decoder are out of order (no jitter buffer)? For example, if order of packets is 0,1,2,4,3,5 (3 and 4 reordered) and there is no FEC. Would it be better, in this case, to drop packet 3 and not decode it at all? Or, if there is FEC, then try to

Hal, No, it is not more of a problem than with DWARF info. DWARF info definitely contains personally identifiable information. However, people usually realize that is the case, and will turn off or strip debug info if they are worried about such issues, or make a specific plan to cleanse that information. You really just want to attempt to eliminate such information to the greatest extent

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

Hi Mircea, If you use an ordinary linker that concatenates .llvmbc sections, you can use this code to get the size of each bitcode module. As far as I know, there's no clean way to separate the .llvmcmd sections without making assumptions about what options were used. // Given a bitcode file followed by garbage, get the size of the actual // bitcode. This only works correctly with some kinds

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

I'm a noob here. I've got a little experience with Ubuntu Linux, and have a good background in Windoze. The newest version of Wine (1.11 I think?) will actually load oovoo!!! Unfortunately it will not allow me to log in to my account... Anyone have any ideas why or what i should do to fix this? It seems a little odd, all it needs is a password right? I triple checked to make sure I was

On Thu, Jan 31, 2019 at 11:05 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That feature is probably too specific to your project. Most projects that > use LTO are using LTO just because it generates better code. Your project > is special as your program itself can also interpret LLVM bitcode, but > that's not the case for most other programs. > I

I am experiencing an issue combining bitcode files for the purpose of generating the combined bitcodes as a single bitcode file. I would like to have any pointers to help me debug this or maybe it has been seen before and a fix is either being worked on or is done. I am using the Xcode 9.0 compiler. I believe the Swift code is 3.x. I have reproduced this using the tot llvm-link. The input

Hi everybody! I'm Josef and I'm working at Oracle Labs on Sulong [1,2], the LLVM IR execution engine in GraalVM [3]. In addition to executing bare bitcode files, Sulong also accepts ELF files with embedded bitcode sections. Therefore, it would be great if LLD in (Full)LTO mode would support embedding bitcode sections to the resulting object file. Is that something that would be

http://bugs.freedesktop.org/show_bug.cgi?id=13843 Summary: swfplay: Fatal IO error 104 (Connection reset by peer) on X server Product: swfdec Version: git Platform: x86-64 (AMD64) URL: http://red-bean.com/proski/loading.swf OS/Version: Linux (All) Status: NEW Severity: normal