Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Darwin vs exceptions"
2007 Dec 08
0
[LLVMdev] Darwin vs exceptions
On Dec 7, 2007, at 4:40 PM, Dale Johannesen wrote:
> So I couldn't get exceptions to work on PPC darwin. After much
> digging and confusion, there seem
> to be two separate issues.
Ok.
> The gcc testsuite is running the version of the unwinding code that
> was built with the local (llvm-)gcc,
> which doesn't work because nobody has implemented
>
2007 Dec 09
1
[LLVMdev] Darwin vs exceptions
Hi Dale,
> > this is the bit I don't understand. Why does it go
> > into a loop? How can the unwinder possibly know that
> > the original code did not have a catch-all, since we
> > tell it which catches there are and we say: there is
> > a catch-all!
>
> The unwinder works by doing a stack crawl to find a handler. Since
> we're telling it
2007 Dec 08
2
[LLVMdev] Darwin vs exceptions
Hi Chris,
> ... Claiming that a function has a
> > catch-all handler when it does
> > not causes the unwinder to go into a loop.
this is the bit I don't understand. Why does it go
into a loop? How can the unwinder possibly know that
the original code did not have a catch-all, since we
tell it which catches there are and we say: there is
a catch-all!
> > -
2007 Dec 10
3
[LLVMdev] Darwin vs exceptions
On Dec 9, 2007, at 1:01 PM, Duncan Sands wrote:
> Hi Dale,
>
>> #include <cstdio>
>> class A {
>> public:
>> A() {}
>> ~A() {}
>> };
>> void f() {
>> A a;
>> throw 5.0;
>> }
>> main() {
>> try {
>> f();
>> } catch(...) { printf("caught\n"); }
>> }
>
> this example
2007 Dec 10
0
[LLVMdev] Darwin vs exceptions
Hi Dale,
> > ... Suppose we don't artificially add catch-alls to
> > selectors. Then
> > the above example compiles to:
> > ...
> I wasn't advocating this; agree it is wrong.
it's maybe not as wrong as it seems since having an empty
selector is equivalent to having a cleanup (IIRC) :)
> > ... If you force a "cleanup" by changing the
2007 Dec 08
0
[LLVMdev] Darwin vs exceptions
On Dec 8, 2007, at 12:51 AM, Duncan Sands wrote:
> Hi Chris,
>
>> ... Claiming that a function has a
>>> catch-all handler when it does
>>> not causes the unwinder to go into a loop.
>
> this is the bit I don't understand. Why does it go
> into a loop? How can the unwinder possibly know that
> the original code did not have a catch-all, since we
2007 Dec 10
3
[LLVMdev] Darwin vs exceptions
On Dec 10, 2007, at 11:38 AM, Duncan Sands wrote:
>>> ... If you force a "cleanup" by changing the selector call to:
>>> %eh_select8.i = tail call i32 (i8*, i8*, ...)*
>>> @llvm.eh.selector.i32( i8* %eh_ptr.i, i8* bitcast (i32 (...)*
>>> @__gxx_personality_v0 to i8*), i32 0)
>>> then it doesn't work either: the unwinder observes that
2007 Dec 08
0
[LLVMdev] Darwin vs exceptions
Hi Dale,
> - Why was C++ claiming that every selector has a catch-all handler?
this is easy: because the semantics of invoke require it. Yes, really.
If unwinding reaches an invoke then control is required to jump to the
unwind basic block. At first I thought this probably wouldn't matter -
that it would be OK to not jump to the landing pad if the exception was
not being caught by it -
2007 Dec 09
3
[LLVMdev] Darwin vs exceptions
(Mail system seems to have eaten this, sorry if it's a repeat)
On Dec 8, 2007, at 12:48 AM, Duncan Sands wrote:
> Hi Dale,
>
>> - Why was C++ claiming that every selector has a catch-all handler?
>
> this is easy: because the semantics of invoke require it. Yes,
> really.
> If unwinding reaches an invoke then control is required to jump to the
> unwind basic
2007 Dec 09
0
[LLVMdev] Darwin vs exceptions
Hi Dale,
> #include <cstdio>
> class A {
> public:
> A() {}
> ~A() {}
> };
> void f() {
> A a;
> throw 5.0;
> }
> main() {
> try {
> f();
> } catch(...) { printf("caught\n"); }
> }
this example indeed shows the problem. Let me explain to see if we agree on what
the problem is. Suppose we don't artificially
2007 Dec 12
0
[LLVMdev] Darwin vs exceptions
Hi Dale,
> No, I don't want to change the semantics of invoke, at least I don't
> think so.
> When inlining, I want the inlined throw to reach cleanup code as it
> does.
> But I want the Unwind_Resume call that ends the cleanup code to be
> replaced with a control transfer to the handler (or cleanup) in the
> calling
> function, i.e. the inliner needs to know
2017 Apr 20
2
Possible stack corruption during call to JITSymbol::getAddress()
Hi David,
Thanks very much for that. I'll continue to dig in as time permits, and
I'll update the bug report with my progress once it's filed.
Cheers,
Lang.
On Mon, Apr 17, 2017 at 6:42 PM, David Lurton <dlurton at gmail.com> wrote:
> Thanks Lang. I think I'll go the bug creation route. I have an email out
> to llvm-admin requesting an account on bugs.llvm.org.
2017 Apr 09
2
Possible stack corruption during call to JITSymbol::getAddress()
Firstly, apologies if this is not the right place to be asking this
question--feel free to point me in the correct direction. I could be doing
something wrong here but stackoverflow didn't feel like the correct place
for this since there's so little there about LLVM ORC.
Basically, I have a reproduction case (below) where if I throw an exception
before I call JITSymbol::getAddress()
2012 Apr 08
2
[LLVMdev] Catching C++ exceptions, cleaning up, rethrowing
On Apr 4, 2012, at 9:32 PM, Paul J. Lucas wrote:
> On Mar 23, 2012, at 4:46 PM, Bill Wendling wrote:
[...]
> This all seems to work just fine. I can throw a C++ exception either in a C++ object's constructor or in an ordinary member function and the stack unwinds correctly (the object's destructors are called) and the exception is propagated back up the C++ code that called the
2017 Apr 17
2
Possible stack corruption during call to JITSymbol::getAddress()
Hi David,
This looks like bad eh-frame data due to a failure to fix up the frame
descriptor entries:
<debug: adding frame> EHFrameAddr: 0x7feae5827000, EHFrameLoadAddr:
0x00000000e5827000, EHFrameSize: 60
==64588==ERROR: AddressSanitizer: SEGV on unknown address 0x7feae5827020
(pc 0x7feae886d970 bp 0x000000000001 sp 0x7ffca10e75f8 T0)
Eyeballing the code in RuntimeDyldELF (vs
2017 May 01
1
Possible stack corruption during call to JITSymbol::getAddress()
Hi David,
Sorry to hear. Has anyone followed up with you yet?
I've continued to dig in to this in my spare time and I've found the issue.
It's a use-after-free, rather than any sort of memory smashing. ORC is
currently failing to deregister the EH-frame section when the JIT is torn
down (but *is* deallocating the memory for it). Normally that's not
disastrous (though it does
2012 Apr 08
0
[LLVMdev] Catching C++ exceptions, cleaning up, rethrowing
On Apr 8, 2012, at 4:20 AM, Bill Wendling wrote:
> On Apr 4, 2012, at 9:32 PM, Paul J. Lucas wrote:
>
>> This all seems to work just fine. I can throw a C++ exception either in a C++ object's constructor or in an ordinary member function and the stack unwinds correctly (the object's destructors are called) and the exception is propagated back up the C++ code that called the
2007 Aug 30
8
[LLVMdev] RFA: Problem with Exceptions
Hi all,
I'm compiling this trivial program on Darwin:
int main(int argc, char **argv) {
try {
throw argc;
} catch(int i) {
return i;
}
return 0;
}
However, it segfaults when I run it. I've attached the .s files
generated by LLVM and GCC, but it looks as if LLVM isn't generating a
gxx_personality_v0 section (like it does for Unwind_Resume, et al). Is
this what's
2013 May 26
1
[LLVMdev] How to always generate epilogue code?
Hi!
I am still working on the Win64 EH code and now have a pretty usable
result. (The MC part is already posted to llvm-commits, the other
part follows soon. If you are curious the whole patch is here:
http://www.redstar.de/ldc/win64eh_all_20130524.diff.)
However, in one case I have a problem with LLVM being too smart.
Consider the following D code:
void doIt()
{
printf("doIt:
2005 Jan 03
1
[LLVMdev] Problem with LLVM CFE bootstrap at FreeBSD
I can't boostrap LLVM CFE at FreeBSD with current LLVM and LLVM CFE CVS
sources.
GCC bootstrap terminated with error:
/usr/home/wanderer/pkg/build/llvm/objcfe/gcc/xgcc -B/usr/home/wanderer/pkg/build/llvm/objcfe/gcc/
-B/home/wanderer/pkg/build
/llvm/night/cfe/i386-unknown-freebsd5.3/bin/ -B/home/wanderer/pkg/build/llvm/night/cfe/i386-unknown-freebsd5.3/lib/
-isystem