public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Robert Lipe <robertl@dgii.com>
To: law@cygnus.com
Cc: acs@acm.org, egcs@cygnus.com, gcc2@cygnus.com,
	Ronald Joe Record <rr@sco.com>
Subject: Re: egcs 10-31 and UnixWare
Date: Sun, 09 Nov 1997 20:32:00 -0000	[thread overview]
Message-ID: <19971109223144.59098@dgii.com> (raw)
In-Reply-To: <14350.879120281@hurl.cygnus.com>

>   > I don't think it's falling through.  It looks like the problem is that
>   > we're in an atexit() function (__do_global_dtors_aux) and it's calling 
>   > the destructor and the destructor is calling exit.   Since exit() will
>   > rip through the atexit() functions, isn't this bad?
> Hmmm, I don't know enough about the language to know how this is supposed
> to be handled.

I can see this as a grey area.     Can anyone cite definitive sources
for expected behaviour?

>   > /usr/tmp/cca003Pz.s:279:defined relocatable values from the same section re > quired, op -
> Bummer.  I suspect this is the funky way it we switch sections under
> gcc's nose in crtstuff.
> 
> Almost makes we wonder if we should be using section attributes to do
> the switching (which gcc knows how to emit proper debug symbols for).

If this is important, we can move this aspect to another thread.
It was just an annoyance I thought I'd mention.

> But I think you've hit the root of the problem -- it looks like we're
> calling exit more than once, which seems to do bad things.

Yes, and this is why removing HAVE_ATEXIT from my target made
the test case pass becuase we weren't calling exit more than
once.

The attached program does different things on the three systems
I tried it on.

OpenServer 5: $   Calls two.   Calls one.  Calls exit.  Calls abort.
Solaris 2.3:   Calls two.   Calls one.   Terminates normally. Exit val 1.
Redhat 4.1/x86: Calls two.   Calls one.  Calls two.  Call two.  Repeats
	until stack size hits 8Mb ulimit.  Faults.


If we decide that calling exit() from a destructor really is a 
questionable idea, we can just change the test case to call _exit()
instead of exit() in the destructor and we can put HAVE_ATEXIT back
in sco5.h.  

Now exactly how this ties into the Unixware stuff at this point,
I'm unsure...



#include <stdio.h>
#include <stdlib.h>

void one(void)
{
        printf("One\n");
        exit(1);
}

void two(void)
{
        printf("two\n");
}


int main(void)
{
        atexit(one);
        atexit(two);
        exit(1);
}


  parent reply	other threads:[~1997-11-09 20:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-11-07  9:25 acs
1997-11-09 10:14 ` Jeffrey A Law
1997-11-09 11:16   ` Robert Lipe
1997-11-09 13:49     ` Jeffrey A Law
1997-11-09 12:35       ` acs
1997-11-09 13:00       ` Robert Lipe
1997-11-09 17:00         ` Jeffrey A Law
1997-11-09 18:35           ` Joe Buck
1997-11-09 21:08             ` Joern Rennecke
1997-11-09 20:32           ` Robert Lipe [this message]
1997-11-10 14:57             ` H.J. Lu
1997-11-10 14:57               ` Robert Lipe
1997-11-10 12:27                 ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19971109223144.59098@dgii.com \
    --to=robertl@dgii.com \
    --cc=acs@acm.org \
    --cc=egcs@cygnus.com \
    --cc=gcc2@cygnus.com \
    --cc=law@cygnus.com \
    --cc=rr@sco.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).