public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] PPC sim: Don't close file descriptors 0, 1, or 2
Date: Tue, 17 Nov 2015 05:41:00 -0000	[thread overview]
Message-ID: <20151117054133.GI31395@vapier.lan> (raw)
In-Reply-To: <20151116210533.058520d2@pinnacle.lan>

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

On 16 Nov 2015 21:05, Kevin Buettner wrote:
> On Mon, 16 Nov 2015 18:53:17 -0500 Mike Frysinger wrote:
> > On 16 Nov 2015 14:58, Kevin Buettner wrote:
> > > This occurs because the powerpc simulator closes, on behalf of the
> > > testcase, the file descriptors associated with stdin, stdout, and
> > > stderr.  GDB still needs these descriptors to communicate with the
> > > user or, in this case, with the testing framework.
> > 
> > special casing this logic in the sim looks wrong to me.  why
> > is the testcase itself trying to close stdin/stdout/stderr ?
> 
> It's not just one test case, but a bunch of them, 229 to be exact.
> 
> I haven't investigated all of them, but in many (if not all) of them,
> close() is being called during exit().  This problem arises when
> GDB runs the testcase to completion.

sounds like that code is broken then ...

> sim/common achieves the same result by placing file descriptors 0, 1,
> 2, and MAX_CALLBACK_FDS together in a circular fd_buddy list.  (See
> os_init() in sim/common/callback.c.) close() is never called on any of
> these descriptors due to the fact that they're in a (circular) list of
> greater than one element.  When one of these descriptors (0, 1, or 2)
> is closed (in os_close()), it is simply removed from the fd_buddy
> list, with no close() operation actually being performed.  Note that
> when the final one is "closed", it is still on an fd_buddy list with
> MAX_CALLBACK_FDS - hence it won't be closed either.
> 
> So sim/common is doing the same thing as my proposed patch for ppc;
> sim/common is just using a more elegant mechanism to avoid calling
> close() on these three file descriptors.

the difference is that this code sequence misbehaves after your change:
	close(1);
	write(1, "foo", 3);
under the common sim, the write will return EBADF.

considering how much of common/ came from ppc/ i'm a little surprised
virtualization of the fd table didn't.

it would be nice if we could at least hide these three fds (a static
array of 3 bools maybe?), but i won't push hard for you to do that.
you should however be making the same change to the other emulation
layers.  you've done it only to netbsd, but the ppc sim has the same
code for the other layers too (like unix, and ...).
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-11-17  5:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-16 21:58 Kevin Buettner
2015-11-16 23:53 ` Mike Frysinger
2015-11-17  4:05   ` Kevin Buettner
2015-11-17  5:41     ` Mike Frysinger [this message]
2015-11-17 20:32       ` Kevin Buettner
2015-11-17 21:05         ` Mike Frysinger
2015-12-07 20:29           ` Kevin Buettner
2015-12-30  0:18             ` Mike Frysinger

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=20151117054133.GI31395@vapier.lan \
    --to=vapier@gentoo.org \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@redhat.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).