Message-Id: <199908120020.AAA29310@out2.ibm.net> From: "Mark E." To: djgpp-workers AT delorie DOT com Date: Wed, 11 Aug 1999 20:19:56 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: patch for i386go32.c In-reply-to: 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 Precedence: bulk > > 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/