Message-Id:	<199908120020.AAA29310@out2.ibm.net>
From:	"Mark E." <snowball3 AT bigfoot DOT com>
To:	djgpp-workers AT delorie DOT com
Date:	Wed, 11 Aug 1999 20:19:56 -0400
MIME-Version:	1.0
Subject:	Re: patch for i386go32.c
In-reply-to:	<B0000097808@stargate.astr.lu.lv>
References:	<199908101850 DOT SAA70660 AT out2 DOT ibm DOT net>
X-mailer:	Pegasus Mail for Win32 (v3.11)
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> > I've searched the DJGPP sources and I can't turn up any references to 
> > __EH_FRAME_{BEGIN,END}__. The one test I made using g++ exceptions shows that 
> > deleting the __EH* symbols and LONG(0) made no difference. So perhaps these symbols 
> > are safe to delete?
> > 
> 
> The following code fragments from src/libc/crt0/crt0.S are "guilty" in 
> that:  lines 48-66 and 295-301 (in current CVS version)
> 
> The related structure is registrated (__register_frame_info) and as 
> result the corresponding definitions from djgpp.djl are not used.
>

Thanks. Then the symbols can be removed. My next patch for i386go32.c will remove 
these symbols.

> The problem is that all should work also without these things in 
> crt0.S (when I did these my tests I mentioned before it didn't work 
> as I expected)
> 

crtstuff.c (that is used to make crtbegin.o and crtend.o) contains similiar code to 
initialize EH. If we switched this the crt*.o method, we could stop having to make 
adjustments to libc every time "they" decide on a better way to do C++ EH. BTW, gcc 
3.0 will have another change in C++ EH, so here comes another chance that C++ EH 
will break.

Mark

--- 
Mark Elbrecht, snowball3 AT bigfoot DOT com
http://snowball.frogspace.net/

- Raw text -