similar to: RFC: auto-generating build dependency file from lld

Yeah, I think there's no reason to not add this to lld/COFF if people find it useful. On Wed, Jul 31, 2019 at 10:25 AM Shi, Steven <steven.shi at intel.com> wrote: > I love this feature. Does it plan to support COFF as well? > > > > > > Thanks > > Steven > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *Rui >

Yes, it's a little bit off-topic, but it is also planned. The data structure that the linker handles can be considered a large graph where vertices are file sections and edges are symbol names. You can say that file A depends on file B if and only if in the graph a section in file A has an edge to a section in file B. There is a plan to dump the graph in a machine-readable format such as JSON

If this is the same test: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/eh/cond1.C.diff?cvsroot=gcc&r1=NONE&r2=1.1, then it doesn't fail for me on Mac OS 10.8 with ASan (Clang r168632) Have you tried symbolizing the report? On Thu, Nov 29, 2012 at 11:07 AM, Alexander Potapenko <glider at google.com> wrote: > Jack, can you please upload this test somewhere?

Nick, Can you take a quick look at the asan_eh_bug.tar.bz testcase I uploaded into the newly opened radr://12777299, "potential pthread/eh bug exposed by libsanitizer". The FSF gcc developers have ported llvm.org's asan code into FSF gcc (and are keeping it synced to the upstream llvm.org code). I have been helping with the darwin build and testing -fsanitize=address against the

+glider The compiler hardly matters here, I would expect the same failures with clang. Alex, could you please take a look? --kcc On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > Nick, > Can you take a quick look at the asan_eh_bug.tar.bz testcase > I uploaded into the newly opened radr://12777299, "potential > pthread/eh bug exposed

Jack, can you please upload this test somewhere? On Thu, Nov 29, 2012 at 10:09 AM, Kostya Serebryany <kcc at google.com> wrote: > +glider > The compiler hardly matters here, I would expect the same failures with > clang. > Alex, could you please take a look? > > --kcc > > > On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >

I debugged this a bit and it seems the mach_override patching of __cxa_throw is bogus. The start of that function is patched to jump to garbage. Breakpoint 1, 0x0000000100001c19 in main () (gdb) display/i $pc 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 <dyld_stub___cxa_throw> (gdb) si 0x0000000100016386 in dyld_stub___cxa_throw () 2: x/i $pc 0x100016386

Looks like this happens on x86_64 because the position of __cxa_throw is too far from the allocated branch island (should be <2G). This can be solved by allocating the branch islands somewhere near the text segment (look for kIslandEnd in asan_mac.cc, this is currently 0x7fffffdf0000) or by patching the function with a longer instruction sequence that stores the jump target in a register and

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Is the native function interposition that is being adopted based on...

Just want to remind everyone that we plan to stop using mach_override in asanin favor of OSX's native function interposition. So, we probably don't want to spend too much effort fixing mach_override. --kcc On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote: > Looks like this happens on x86_64 because the position of __cxa_throw > is too far from

I have an ASAN enabled version of R-devel on my test machine, and can get it to relably crash.? Here is the first part of the session: tmt-local2434% R --vanilla R Under development (unstable) (2019-06-28 r76752) -- "Unsuffered Consequences" Platform: x86_64-pc-linux-gnu (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under

+kremenek, ganna On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > Just want to remind everyone that we plan to stop using mach_override in > > asanin favor of OSX's native function interposition. > > So, we probably don't want to spend too much effort fixing

On Sat, Dec 01, 2012 at 05:42:15PM +0400, Kostya Serebryany wrote: > +kremenek, ganna > > On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > > > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > > Just want to remind everyone that we plan to stop using mach_override in > > > asanin favor of OSX's

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Unless I am misunderstanding the code in asan/asan_intercepted_functions.h,

On Tue, Dec 04, 2012 at 10:36:18AM -0800, Alexander Potapenko wrote: > Currently the replacement of allocation routines is based on creating > a new malloc zone and a new CFAllocator (because the allocator > replacement is done later than it could be, we must have both). This > makes us depend on CoreFoundation to call CFAllocatorSetDefault. > Because of some bugs in CF which start

Hi all, I have haskell code that calls into C code and i'd like to compile the C code with ASAN. I've managed to convince the build system to compile the C code with '-fsanitize=address -g' (so that if I get a link errors of the ASAN library isn't linked) and then also managed to link libasan, but when my trivial test program with an obvious out-of-bounds access run, I

Hello, I am building sanitizers for our different platforms and trying to use it in an example program, but while it seems like ASAN is running it's init functions (see stdout below with ASAN_OPTIONS=verbosity=1) it never catches anything in the program. This is LLVM 8.0.1 btw. I was using this small test case: int main(int argc, char** argv) { int *array = new int[100]; delete []

Currently the replacement of allocation routines is based on creating a new malloc zone and a new CFAllocator (because the allocator replacement is done later than it could be, we must have both). This makes us depend on CoreFoundation to call CFAllocatorSetDefault. Because of some bugs in CF which start firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of

On 09/25/2015 11:53 AM, Jakub Jelinek via llvm-dev wrote: > On Fri, Sep 25, 2015 at 01:19:48AM -0700, Renato Golin wrote: >> After long talks with lots of people, I think we have a winning >> strategy to deal with the variable nature of VMA address in AArch64. >> It seems that the best way forward is to try the dynamic calculation >> at runtime, evaluate the performance,

Hello Alex, Thanks for the hint. It was actually not the -O flag that created the problem. But it pointed me in the right direction, when I passed -fno-experimental-new-pass-manager it started to show the error. My guess is that the new pass manager is more aggressive in removing UB? Thanks, Tobias On Mon, Feb 3, 2020 at 5:29 PM Alex Brachet-Mialot <alexbrachetmialot at gmail.com> wrote: