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);
}
next prev 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).