search for: codesafeti

Dear Boris, I managed to see your question and rescue it from the llvm-announce mailing list filter. I'm forwarding your question to the llvmdev at cs.uiuc.edu mailing list; that list is used for questions and answers about LLVM. For future reference, the llvm-announce list is used to send announcements regarding LLVM releases. The llvmdev list is for general discussion. Now, on to

(Note to self: learn to scan the full digest for later messages in a thread before replying to an earlier message.) Ed, Your reply to John answered some of my questions, but not all, and raised a new one: > Maybe I should have been a bit clearer; we're really interested in full > memory and type safety. We want to harden the system against memory > corruption vulnerabilities.

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

Hi Reid, --- Reid Spencer <rspencer at reidspencer.com> wrote: > On Tue, 2006-12-19 at 17:32 -0800, Roman Levenstein wrote: > > But since the new llvm-dis cannot disassemble, I cannot use > > llvm-upgrade, since I need a way to produce an *.ll file. > > If you can't do as Bill suggested (get the latest llvm-gcc and > compile > it), you can use this approach:

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