similar to: [LLVMdev] LLVM Language Reference Strictness

On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy <shea at shealevy.com> wrote: > Hello, > > I'd like write a program that performs static analysis of code at the > LLVM assembly/bitcode level, and to do so I plan on extensively > referencing the language reference. As I hope to eventually use this > tool as part of a security analysis of untrusted code, I need to be >

On 10/19/11 11:58 PM, Eli Friedman wrote: > On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy<shea at shealevy.com> wrote: >> 2. Are target-specific behaviors documented for each supported target? > When anything has target-specific behavior, that fact should be > documented. Beyond that, if you have a question about what some > construct is supposed to do, please ask. What I

On Thu, Oct 20, 2011 at 2:37 AM, Shea Levy <shea at shealevy.com> wrote: >. The > (probably impossible) end-goals to this project would be a) that every > program which passes its checks would be as safe to run in kernel mode > with full memory access as it would be in user mode That would be a very useful thing to have for embedded systems. Some such as uCLinux run ports of

On Oct 20, 2011, at 2:37 AM, Shea Levy wrote: > On 10/19/11 11:58 PM, Eli Friedman wrote: >> On Wed, Oct 19, 2011 at 8:20 PM, Shea Levy<shea at shealevy.com> wrote: >>> 2. Are target-specific behaviors documented for each supported target? >> When anything has target-specific behavior, that fact should be >> documented. Beyond that, if you have a question

On 05/02/2012 01:00 PM, Dave Zarzycki wrote: > Shea, > > Feasible? Sure, anything is feasible. A good idea? Not really. The internal lld file format is an _intermediate_ data structure designed to make creating the final executable straightforward and fast. It isn't designed to be an executable format itself. In fact, the reason why linkers can often be slow is because the

Hello, Would it be feasible to use the internal lld file format as the native executable format for an OS? Are there performance or space considerations that would make this a poor choice? Cheers, Shea Levy P.S. please CC me on replies, I'm not subscribed.

Shea, Feasible? Sure, anything is feasible. A good idea? Not really. The internal lld file format is an _intermediate_ data structure designed to make creating the final executable straightforward and fast. It isn't designed to be an executable format itself. In fact, the reason why linkers can often be slow is because the intermediate and final object file formats are conflated. davez On

> > On Oct 20, 2011, at 3:13 AM, Shea Levy wrote: > >> Hello, >> >> The llvm 2.9 configure script fails to check for groff, causing a >> failure very late in the game when building man pages, and, on OSX, >> sw_vers. I'll try to write a patch for this myself, but autoconf is >> largely black magic to me so I thought I'd throw this out there in

On 12/19/11 7:19 PM, Howard Hinnant wrote: > On Dec 19, 2011, at 7:14 PM, Shea Levy wrote: > >> Hello all, >> >> Is it possible, if using libc++ and compiler-rt, to have a clang with no >> runtime dependencies on any GCC components on Linux? If not, will this >> ever be possible? > We are working on a new libc++abi: http://libcxxabi.llvm.org/ which carries

Hi all, I'm hitting a segfault in llc when trying to build GHC: http://sprunge.us/ZVGB. What is the best way to debug this? I'm able to bump to 3.8.1 if needed, but GHC tends to break when updating major versions due to IR incompatibilities. Thanks, Shea -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size:

I found a fix! The first hunk of https://reviews.llvm.org/D17533 (lib/CodeGen/TargetFrameLoweringImpl.cpp) on top of 3.8.1 does the trick. Does llvm do patch releases of old versions? Davide Italiano <davide at freebsd.org> writes: > On Fri, Oct 21, 2016 at 6:19 AM, Shea Levy via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Hi all, >> >> I'm hitting

Hello, The llvm 2.9 configure script fails to check for groff, causing a failure very late in the game when building man pages, and, on OSX, sw_vers. I'll try to write a patch for this myself, but autoconf is largely black magic to me so I thought I'd throw this out there in case someone more experienced in this stuff wants to fix this. Cheers, Shea Levy

Hello all, Is it possible, if using libc++ and compiler-rt, to have a clang with no runtime dependencies on any GCC components on Linux? If not, will this ever be possible? Cheers, Shea Levy

On 5/2/12 10:29 AM, Shea Levy wrote: > Hello, > > Would it be feasible to use the internal lld file format as the native > executable format for an OS? Are there performance or space > considerations that would make this a poor choice? By lld, do you mean the LLVM IR bitcode format, or are you referring to something else? As far as using LLVM IR as a format for executables, there

On 10/20/2011 07:42 AM, Duncan Sands wrote: >> For the level of specificity you're looking for, just the source code itself. The LLVM IR language documentation is not, and isn't intended to be, a true language standard document in the same way that the C or C++ standards are. For any given case, check the docs first, and if your question isn't answered there, check the source

> For the level of specificity you're looking for, just the source code itself. The LLVM IR language documentation is not, and isn't intended to be, a true language standard document in the same way that the C or C++ standards are. For any given case, check the docs first, and if your question isn't answered there, check the source code of the target(s) you're interested in.

On 10/21/2011 09:28 AM, Owen Anderson wrote: > Reed, > > On Oct 20, 2011, at 9:47 AM, Reed Kotler wrote: >> I would like to see the many adhoc parsers in LLVM get replaced by ones >> generated from grammars. > > FYI, this is very unlikely to happen. The parsers in LLVM /were/ > historically generated from grammars (bison, as I recall), and those >

Reed, On Oct 20, 2011, at 9:47 AM, Reed Kotler wrote: > I would like to see the many adhoc parsers in LLVM get replaced by ones > generated from grammars. FYI, this is very unlikely to happen. The parsers in LLVM were historically generated from grammars (bison, as I recall), and those implementations were removed in favor of hand-written implementations both because the latter were

Reed, Are you working on a grammar of the LLVM syntax or also on a full semantics? Steve Zdancewic's group at U. Penn. is working on a formal operational semantics for LLVM. It is partially complete and Greg Morrisett at Harvard is planning to build further on it. Regards, --Vikram Professor, Computer Science University of Illinois at Urbana-Champaign http://llvm.org/~vadve On Oct 20,

Dear list, http://www.llvm.org/docs/LangRef.html#visibility-styles says "A symbol with internal or private linkage must have default visibility." I think it should be protected visibility. -- Best Regards, Yu Rong Tan