Re: 2nd posting: exceptions and asm() blocks on x86

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"John S. Yates, Jr." <jyates@xxxxxxxxxxx> writes:

> > "Falk Hueffner" <falk.hueffner@xxxxxxxxxxxxxxxxxxxxxxxx> writes:
> >
> > It's an expected limitation. asm's are not supposed to
> > change the control flow. The manual could probably more
> > explicit about this...
> 
> I find this assertion hard to believe.  The gcc manual shows an
> explicit example of using an asm() to make a call.  If your
> assertion is truly gcc's reasoned design intent then it implies that
> any author of an asm() containing a call is responsible for ensuring
> that the transitive closure of all code reachable from that call is
> and remains free of exception possibilities for all time.  Surely
> such drastic consequences from a design choice would have merited a
> cautionary comment of some sort...
> 
> I therefore put it to you that this is not simply a deficiency in
> gcc documentation but rather a legitimate bug.  True, a fix might
> require additional syntax...  But as things stand asm() is a
> festering gotcha.

I basically agree. I suggest you file a bug report against the
documentation for not documenting the status quo properly. Then you
might also file a bug report asking for a mechanism to make this work
reliably.

> > Maybe you could try to generate the required .eh_frames manually,
> > I think the Linux kernel does this somewhere.
> 
> I am desperate and willing to try anything.  Searching the web
> based-on your suggestion I found the following article:
> 
> http://www.tldp.org/LDP/khg/HyperNews/get/devices/exceptions.html
> 
> I believe I could indeed do something similar if I knew enough
> about the contents of .eh_frames.  So far though I have had no
> luck looking for documentation.  Any suggestions?

As a bit of voodoo, try not to use -fomit-frame-pointer in case you
currently do, and try adding memory to the clobber list (you should
probably do that anyway, since the functions you call might change
memory).

This article gives some overview of the EH mechanism:
http://gcc.gnu.org/ml/gcc/2002-07/msg00391.html

Other than that, I've no idea either...

-- 
	Falk


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux