search for: __cxa_throw

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 j...

...elease tarballs on OS X 10.5 PowerPC. I'm building out-of-tree mostly following https://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary . Cmake gets this far and hangs: -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Looking for __cxa_throw in c++ -- Looking for __cxa_throw in c++ - not found -- Looking for __cxa_throw in stdc++ -- Looking for __cxa_throw in stdc++ - found The Cmake script does not appear to move on to other tests like "-- Looking for __i686__" (if https://lists.llvm.org/pipermail/llvm-dev/2016-December/108...

...e 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 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 > s...

...y method used will be transparent to the user and not require manually setting DYLD_INSERT_LIBRARIES, correct? Jack > > 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 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 longe...

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 0x1000...

Hi Duncan, >>are you trying to get the name "@_ZTIi" or "@__cxa_throw"? yes! i want get the name @_ZTi or @__cxa_throw, the latter @__cxa_throw i can get it throw value->getName(), but the @_ZTi it did n't has name! zhangzw thanks 2009/3/26 Duncan Sands <baldrick at free.fr>: > Hi zhangzw, > >> invoke void @__cxa_throw(i8* %7, i...

...ck with mach_override until someone steps up to implement the missing blocks support for darwin in FSF gcc. Jack > > 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 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 longe...

...mplement the missing blocks support for darwin in FSF gcc. > --kcc > Jack > > > > > 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 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 f...

...arent to the user and not require > manually setting DYLD_INSERT_LIBRARIES, correct? > Jack > >> >> 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 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 funct...

...gt; > > --kcc > > > > > Jack > > > > > > > > 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 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)...

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> >

Hi zhangzw, >> invoke void @__cxa_throw(i8* %7, i8* bitcast >> (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* >> null) >> noreturn to label %invcont unwind label %lpad > > >>are you trying to get the name "@_ZTIi" or "@__cxa_throw"? > > yes! i want get...

Hi Duncan, thanks ! hehe . >> Why do you want the names anyway? because i 'am working on llvm to support sjlj-eh for my target. for my side, I lookup the llvm invoke instruction to build the sjlj-eh on sjlj-eh it's need store the landing pad index to stack before call __cxa_throw, but it seems no ! in llvm-backend because it only suport dwarf-eh! so i have to build another node to store landingpad index to stack before llvm invoke instruction. am i write for the direction? hehe. zhangzw 2009/3/26 Duncan Sands <baldrick at free.fr>: > Hi zhangzw, >...

HI all, here is a llvm IR : invoke void @__cxa_throw(i8* %7, i8* bitcast (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* null) noreturn to label %invcont unwind label %lpad say I want to get the Invoke's Operand's name, I use getOperand(i)->getName(), it can work for that the Operand hasname, but some Opera...

Hi zhangzw, > invoke void @__cxa_throw(i8* %7, i8* bitcast > (%struct.__fundamental_type_info_pseudo* @_ZTIi to i8*), void (i8*)* > null) > noreturn to label %invcont unwind label %lpad > > say I want to get the Invoke's Operand's name are you trying to get the name "@_ZTIi" or "@__cxa_th...

When I compile some code with the near-trunk clang++ I get this: ... tail call void @_Unwind_Resume_or_Rethrow(i8* %exn2) noreturn unreachable ... declare void @_Unwind_Resume_or_Rethrow(i8*) ... Same with __cxa_throw. 'noreturn' is missing on declarations. This seems to be a bug. Also can _Unwind_Resume_or_Rethrow actually return? When I run some simple exception code in JIT I see that this function actually returns and then SEGVs. Yuri

Can you point out to me where in the VMKit code I should be looking? I spent some additional time reading the docs, and I have some specific questions: 1) I'm trying to figure out the relationship between the __cxa_throw function, and the _Unwind_RaiseException function mentioned in the ABI doc. My guess is that _Unwind_RaiseException is the language-neutral implementation of stack unwinding, and __cxa_throw is the C++ exception semantics that are implemented on top of it. If that is the case, should I be calling _...

Hi Duncan, >>I don't get it. Sorry my bad English! hehe. >>What has this got to do with determining the >>names "@__cxa_throw" and "@_ZTi"? Record the Information into the MachineModule Info, so in Dwarfwriter or SjLjWriter(my sjlj-eh name) can build the except table correctly! 2009/3/26 Duncan Sands <baldrick at free.fr>: > Hi zhangzw, > >> >> Why do you want the names anyway? &g...

...me code with the near-trunk clang++ I get this: Please send clang-specific questions to cfe-dev at cs.uiuc.edu. > ... > tail call void @_Unwind_Resume_or_Rethrow(i8* %exn2) noreturn > unreachable > ... > declare void @_Unwind_Resume_or_Rethrow(i8*) > ... > > Same with __cxa_throw. 'noreturn' is missing on declarations. > This seems to be a bug. It really shouldn't make a difference; the call site should take priority anyway. > Also can _Unwind_Resume_or_Rethrow actually return? When I run some > simple exception code in JIT I see that this function...

...ding file 'mylib.a' > > $ llc -o=cbe.c -march=c linked.o > > WARNING: this target does not support the llvm.stacksave intrinsic. > > $ gcc cbe.c > > /var/tmp//ccVAM4W2.o(.text+0x329a): In function `operator new(unsigned int)': > > : undefined reference to `__cxa_throw' > > [...and more errors] > > $ > > > > But __cxa_throw is right there, in sup/eh_throw.o, and in linked.o, it > > just isn't being emitted as C code. (at this point, I suspect the > > problem might be that I don't quite understand how some of the l...