delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/08/11/20:43:52

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019