This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GCC 3.2] dll/exe exceptions patch

On Thu, 2002-08-01 at 12:35, Danny Smith wrote:
> > I'd like to provide feedback, but am short of cycles myself. Can you
> > describe what it does? I can likely tell any (obvious) collisions with
> > cygwin from that.
> > 
> > Rob
> > 
> > 
> For mingw (without a special EH dll):
> The patch uses the win32api  FindAtom/AddAtom functions to create/find a local
> ATOM for an app.
> In the atom api, the atom string is case insensitive. This is used to
> advantage.  The string is coded so that 1=uppercase, 0=lowercase.  En/decoding
> the 'binary' string to a long int, cast to a void*, allows common access to
> malloc'd array that contains the addresses of EH objects.  The main .exe adds
> the local atom (and define the eh globals in the exe address space).  Dlls 
> find the local atom.  They all use the same addresses when unwinding. So no
> problems with crossing dll/exe boundaries.
> Not very well explained.  The patch itself tells the story though. 
> The concept may be usefully extended to other 'shared' globals.  I'm looking at
> objc now. 
> For cygwin.
> The above works for cygwin  too.  There may be a better way that avoids the
> ATOM api.

This will not interact with pthreads at all AFAIK, as pthreads leverages
the native threads. If FindAtom is threadsafe on mingw, it will be on
Cygwin. As to using a better API, we can probably write one, but why

Lastly, wouldn't SEH be a feasible alternative (if the ReactOS work is


Attachment: signature.asc
Description: This is a digitally signed message part

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]