similar to: [GSoC 2016] SAFECode's Memory Policy Hardening - Midterm Report - Zhengyang Liu

Dear LLVM and SVA community: This is to brief you the progress of this week. I mainly focused on minor fixes this week. Following is what I finished this week. 1. Move the implementation of runOnModule of RegisterGlobalVar pass from .h back to .cpp file. 2. Introduce two new functions to register and unregister function prototypes on llvm.compiler.used. 3. Added two regression tests for

Abstraction ---------------------------------- This projects will enhance the ‘Baggy Bounds with Accurate Checking’ [1] work. I will provide more efficient runtime checks in BBAC framework by adding more informations to the memory object’s padding area. A new padding area scheme will be designed to make these informations compact and efficient to fetch. I will create some new runtime checks on

First of all, I am really sorry about my time scheduling. I did not manage to upload my proposal at the last minutes before Google Summer of Code submission deadline. Could you kindly take the following revision as my final proposal? Abstraction --------------------- This projects will enhance the ‘Baggy Bounds with Accurate Checking’ (BBAC) [1] work. By adding information to the memory object’s

Hi, everyone This proposal covers the OpenProjects idea 'Port the Bigloo Scheme compiler, from Manuel Serrano at INRIA Sophia-Antipolis, to output LLVM bytecode.' There is not a popular functional language frontend yet on LLVM. To my knowledge, this is mostly because LLVM is lack of runtime support for the functional language needs, and C foreign function interface calls are relatively

Dear John, > When you say "must be allocated," you mean it must have been allocated via a call to a heap allocator (e.g., malloc(), calloc(), etc), correct? Yes, I mean heap allocators. In fact, I'm implementing the idea of the ICSE 2015 paper Safe Memory-Leak Fixing for C Programs. > Also, are you performing intra-procedural or inter-procedural data-flow analysis?

On 08/10/2011 11:03 AM, Sanjoy Das wrote: > Hi! > > Attached my pre-midterm GSoC work for segmented stacks for review (with > the required fixes). Nice work! + extern bool EnableSegmentedStacks; Can you add a comment like the other declarations? I think the patch looks good. There are possible improvements, but the patch is already in an state where it can be tested and extended

Hi everyone! My flang GSoC has been going great so far, and I have achieved a lot. I wrote a report describing some of the results and instructions on how to use flang: http://flang-gsoc.blogspot.ie/2013/07/gsoc-midterm-progress-report.html Alex -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi I have an asterisk box with digium hardware connected to a Siemens EWSD version 15 using a crossed E1 cable. The asterisk is serving as a h323 media gateway. When i start asterisk, the Siemens gives me this alarm: REPORTES GENERADOS EN LA EWSD AES/V15SBOL/BOLCBK1V51327079/013 05-06-06 11:25:38 7773 3062/03728 HF.ARCHIVE-80040

John Criswell wrote: > If you're interested in SAFECode, the first step is to get SAFECode > working with a newer version of LLVM. A Master's student did some > work on this last summer with LLVM 3.7 but didn't finish. It would > now need to be updated to LLVM 3.8 (though I suppose a completed LLVM > 3.7 port would be fine with me). > > After that, there are

Hi! Attached my pre-midterm GSoC work for segmented stacks for review (with the required fixes). Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-New-command-line-option-to-enable-segmented-stacks.patch Type: text/x-diff Size: 1699 bytes Desc: not available URL:

On Tue, Aug 16, 2011 at 09:06:52AM +0200, Duncan Sands wrote: > thanks for working on this! As far as I know, split stacks are the only thing > special to GCC Go, otherwise the generic GCC infrastructure was enough. Not true. At least on x86_64, Go uses a different calling convention. Joerg

> thanks for working on this! As far as I know, split stacks are the only thing > special to GCC Go, otherwise the generic GCC infrastructure was enough. If that > is true then you shouldn't need to do more than what you described above, except > for poking at things until they work of course! The usual source of trouble is > when front-ends trying to write things directly to

As far as I can see (after hand-tweaking the assembly generated for a simple example), there is no problem with the calling convention. Also, go_write_export_data only seems to generate to some sort of debug information (which does not look like DWARF). However, there seems to be some problem with how LLVM handles trampolines -- I'm currently trying find out what exactly the problem is. --

Dear Sanjoy Das and community. I was tried to fix a bug in the pass InitAllocas from SAFECode. This is a function pass and will insert a prototype of 'llvm.memset.p0i8.i32' in the module at doInitialize() stage of the pass. But, this prototype will be eliminated by strip unused function optimization since there is no call on this function after doInitialization(). Therefore there will be

Hi Sanjoy, > I've been working on coroutines for some time, and it seems you were > right - it makes much more sense to have regular C (and assembly) code > for handling coroutines. For instance, I'd otherwise would have to > make an assumption about the threading model the platform has (or > assume there are no threads at all, which prevents me from allowing > goroutine

Dear Michael, If you're interested in SAFECode, the first step is to get SAFECode working with a newer version of LLVM. A Master's student did some work on this last summer with LLVM 3.7 but didn't finish. It would now need to be updated to LLVM 3.8 (though I suppose a completed LLVM 3.7 port would be fine with me). After that, there are some interesting projects on which to

Greetings, Our telco called last week, saying that a lot of channels on our PRIs are blocked. And with blocked they have the following description in the Siemens exchanges: BBAC BLOCKED BACKWARD This status is set when the partner exchange has a blocking set and the signaling of the trunk (non-CCS7) is able to report this blocking in the backward direction. This status can

Dear GSoC Students and Mentors, This is just a reminder about midterm evaluations which start on next week. So, starting from 19:00 UTC July, 11 till 19:00 UTC July, 15 you can submit your midterm evaluation forms. If you will be unable due to some reason to fill the midterm evaluation form, please let me know asap. Thanks! -- With best regards, Anton Korobeynikov Faculty of Mathematics and

Hi! I've been working on coroutines for some time, and it seems you were right - it makes much more sense to have regular C (and assembly) code for handling coroutines. For instance, I'd otherwise would have to make an assumption about the threading model the platform has (or assume there are no threads at all, which prevents me from allowing goroutine like ("run parallel till you

Dear Community, in an earlier post, students working on LLVM were asked to provide a short report on their GSoC project. in the following I want to give an overview on the current status of my GSoC project and outline my next planned activities. Since my mentoring organization is Julia, I also send this to the according mailing list. *1. Activities so far:* As described in my proposal [1], I