Update to GGC Binary Page
Colin Prior & Steve Christensen from UNIX Packages/Sunfreeware. We have been providing GCC as a binary for Solaris for over 20 years. Initially under sponsorship on www.sunfreeware.com and then more recently via our subscription site www.unixpackages.com We aim to make new binary versions available for any Solaris package that has a security issue within 24 hours of being notified. We are looking to update the link on the GCC Binary page http://gcc.gnu.org/install/binaries.html and note that it is not under CVS control So we are writing to you to request that it is updated. Please can you replace the link to Sunfreeware on your Installing GCC: Binary Page with UNIX Packages http://www.unixpackages.com Versions for Solaris 2.5 - 11 SPARC and X86 Many thanks in advance Steve & Colin Colin Prior UNIX Packages +1 206 310 4610 co...@unixpackages.com
Re: stack-protection vs alloca vs dwarf2
On 04/17/2014 10:14 AM, DJ Delorie wrote: > _medium_frame: > pushm r6-r12 > add #-4, r0, r6 ; marked frame-related (fp = sp - 4) > mov.L r6, r0 ; marked frame-related (sp = fp) There's your bug. If the frame pointer is required, you shouldn't mark that third insn as frame related. With this sequence, the auto-guessing code is assuming that r6 is just a computational temporary and that sp is still the cfa. r~
Re: stack-protection vs alloca vs dwarf2
On 04/18/2014 11:31 PM, Richard Henderson wrote: > On 04/17/2014 10:14 AM, DJ Delorie wrote: >> _medium_frame: >> pushm r6-r12 >> add #-4, r0, r6 ; marked frame-related (fp = sp - 4) >> mov.L r6, r0 ; marked frame-related (sp = fp) > > There's your bug. If the frame pointer is required, you shouldn't mark that > third insn as frame related. > > With this sequence, the auto-guessing code is assuming that r6 is just a > computational temporary and that sp is still the cfa. This auto-guessing mistake is why I strongly recommend not using it if possible. Better to use explicit REG_CFA_DEF_CFA (et al) notes. Certainly one *must* use the explicit notes for the epilogue. r~
Re: stack-protection vs alloca vs dwarf2
> Also, is that rule true if we *don't* have a frame pointer? That is, > when we add a constant to the stack to allocate the frame, should that > function be marked as frame-related? Or is it just the fp->sp move > (or potentially an add, if there's outgoing args) that shouldn't be > marked? The prologue expansion code needs to know what it is doing, in the sense that it needs to know what register is the CFA register and what insn sets it up. Once the CFA register is set up, insns modifying other registers, including sp if sp is not the CFA register, must not be marked; of course, if sp is the CFA register throughout the function because there is no frame pointer, then all insns modifying sp must be marked. -- Eric Botcazou
how to mark a memory address so that it's not instrumented by tsan
Hi, I'm trying to build a race detector for Cilk programs (as an open-source alternative to the closed-source Intel cilkscreen race detector). I'm trying to use the -fsanitize=thread to instrument the loads and stores, and I'm also use -fcilkplus to generate cilk code at the same time. My plan is to replace the tsan library with my own library that uses a near-linear time race detection algorithm. (A race detector that works on nested fork-join parallel programs can be faster than a general race detector which must cope with arbitrary dependencies). So here's the problem: -fcilkplus introduces extra loads and stores into the code, to interact with Cilk's work stealing scheduler runtime system. I don't want those loads and stores to be instrumented with calls such as tsan_write4(). Is there some way to mark a memory access so that it's not instrumented by tsan? Cheers -Bradley
