From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16350 invoked by alias); 2 Jul 2016 14:04:53 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 16335 invoked by uid 89); 2 Jul 2016 14:04:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:976, H*MI:sk:9560791, H*i:sk:9560791, H*f:sk:302246a X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 02 Jul 2016 14:04:42 +0000 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 38.2C.09012.A8FB7775; Sat, 2 Jul 2016 15:20:11 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0294.000; Sat, 2 Jul 2016 10:04:39 -0400 From: Marc Khouzam To: Simon Marchi , Pedro Alves CC: "gdb@sourceware.org" Subject: RE: Is there a way to unset inferior-tty? Date: Sat, 02 Jul 2016 14:04:00 -0000 Message-ID: References: <302246af-a394-4a76-5223-5cac924bda9a@redhat.com>,<9560791fd070c79f7ab54e5e7b63d433@simark.ca> In-Reply-To: <9560791fd070c79f7ab54e5e7b63d433@simark.ca> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00004.txt.bz2 > > I think this should just be fixed to work. > >=20 > > The fix should be very similar to this: > >=20 > >=20 > > https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D811a659a= 779fdf93293fe1105d99e9db171a8b68 > >=20 > > Thanks, > > Pedro Alves >=20 > Hi Marc, >=20 > Here's a patch. If you like it I'll submit it to gdb-patches with=20 > ChangeLog and all. Thanks! Might as well submit it. In the end I moved to a more complete solution for eclipse. Right after an inferior starts, eclipse will reset the tty to a new and valid value; that way, if the user does a 'run', the tty will already be properly set _and_ will direct inferior output to a valid eclipse console. FWIW, this also led me to automatically set the tty for an inferior that is created using the GDB console with the 'add-inferior' command (thanks to the =3Dthread-group-added event). I think this will make for an improved user experience with the GDB console in eclipse. Marc >From gdb-return-45171-listarch-gdb=sources.redhat.com@sourceware.org Mon Jul 04 02:16:10 2016 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 61614 invoked by alias); 4 Jul 2016 02:16:09 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Delivered-To: mailing list gdb@sourceware.org Received: (qmail 61602 invoked by uid 89); 4 Jul 2016 02:16:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=BAYES_05,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Julio, pipes, H*Ad:D*io, HTo:D*io X-HELO: smtp.gentoo.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Jul 2016 02:16:07 +0000 Received: from vapier.lan (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with SMTP id 58B5F340D81; Mon, 4 Jul 2016 02:16:05 +0000 (UTC) Date: Mon, 04 Jul 2016 02:16:00 -0000 From: Mike Frysinger To: Julio Guerra Cc: gdb@sourceware.org, Corinna Vinschen , Christophe =?utf-8?Q?Pl=C3=A9?= Subject: Re: [RFC] Remote File I/O should allow opening non regular files Message-ID: <20160704021605.GP4685@vapier.lan> Mail-Followup-To: Julio Guerra , gdb@sourceware.org, Corinna Vinschen , Christophe =?utf-8?Q?Pl=C3=A9?= References: <42ab0baf-9cf0-76a5-17c8-fa04940dd1bb@farjump.io> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JVVqWhpkAs5raV7A" Content-Disposition: inline In-Reply-To: <42ab0baf-9cf0-76a5-17c8-fa04940dd1bb@farjump.io> X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00005.txt.bz2 --JVVqWhpkAs5raV7A Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-length: 758 On 02 Jul 2016 14:02, Julio Guerra wrote: > Today's implementation of `open()` first checks if the file is a regular > file [1]. Is there any good reason for that limitation? I can't see any > problem in opening special files. Most of them can be used with `read()` > and `write()` only, without `ioctl()`, like any regular file. For > example: TTYs, /dev/random, pipes, etc. makes sense to me to delete that entire stat block of code. it seems like remote_fileio_return_errno should DTRT all the time (like trying to open a dir and failing). although that edge case might be worth checking. i'd note that the current code is even racy (TOCTOU) so at the very least, it should do the open first, and then fstat the fd to do all of the type checks. -mike --JVVqWhpkAs5raV7A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXecbkAAoJEEFjO5/oN/WBG0YQAJhNfFDhTXIbwE4k96wonqEU 1GGFyOHiStj/ynLWkzhYac8ICkEk+MLZ4KslfRv+fpiIXDdOH1BV1kKQqmPCgWDG gmIqzjX3eGKsWTsrVJN3Rb4tGr7w0MbQv9ffsilrZJgtlkKxzc62PB0V812ZYlvn uTKgC5+qcgw4ELl2Kw6oiAfqKEwxxB2fprlGM25FbUuntOzhTug6g5huC5dxnYGz VuapPoFgKKgp34N3nkLJHMyhGXZgGfGvsWcszbMG9nhDbUH8JCsRMOXbUjuNi4gZ BipB7Jr1IqLyC9HLSqb+bNvPt8Yx9hntQnEp9RCfSCpfHjukkOZIXBEm+rEUObkL t2LuYR8Zo8ApLd/6qp4WiBwo7pB7CeQBPiUhzVE+Ck5mf9W6ZEAQ+mgNPVc/2s+x FYR6LL2lrFRXhrNECHaBZorH/nfA8Ftj4jgFmMxkC6xlQazv9VSGEh3PmXb6e2BM fZT/GfqBDvh6NZWGycFYkWJSTVB9B6OKwdjm4/q//RSjx5cVkoSxXx4IhbQMVSiF +ZW4iFtxy3N3eqmy30zp1rltZmLKLsHq5AU1ND5IqjVDuFs+S5jfTEMkQi6whn/S dXH1ZXbLJbRdQF5WPytY1wPU5xoEvIvRvBPI+rRCSkgNR0q0N10aNyw4Y6KNXezd 0dsqyozkF9qSQQ2aX2uu =e703 -----END PGP SIGNATURE----- --JVVqWhpkAs5raV7A--