From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103776 invoked by alias); 18 Dec 2019 18:33:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 103766 invoked by uid 89); 18 Dec 2019 18:33:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=stone, complications, emulated X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Dec 2019 18:32:57 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47894) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ihe7y-0002Ld-RM; Wed, 18 Dec 2019 13:32:55 -0500 Received: from [176.228.60.248] (port=4721 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ihe7x-0006eF-U4; Wed, 18 Dec 2019 13:32:54 -0500 Date: Wed, 18 Dec 2019 18:33:00 -0000 Message-Id: <83k16t32no.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: philippe.waroquiers@skynet.be, gdb-patches@sourceware.org In-reply-to: <3aacf88f-212e-f11f-0688-4f8219dab4c3@redhat.com> (message from Pedro Alves on Wed, 18 Dec 2019 17:42:28 +0000) Subject: Re: [RFAv3 2/6] Improve process exit status macros on MinGW References: <20190504161753.15530-1-philippe.waroquiers@skynet.be> <20190504161753.15530-3-philippe.waroquiers@skynet.be> <835zie51mf.fsf@gnu.org> <52c4ca33-ffc4-8e1e-fe08-a92123ef02aa@redhat.com> <83o8w536l6.fsf@gnu.org> <3aacf88f-212e-f11f-0688-4f8219dab4c3@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00781.txt.bz2 > Cc: philippe.waroquiers@skynet.be, gdb-patches@sourceware.org > From: Pedro Alves > Date: Wed, 18 Dec 2019 17:42:28 +0000 > > > A new file for just one function sounds too much to me. Is it OK to > > define an inline function in gdb_wait.h, as in the prototype change > > below? If this way is accepted, I will post a fully formatted patch. > > I don't think it's too much. As a static inline function means that > you end up with multiple versions of the function, including > the mapping array, in the gdb binary. And also make gdb_wait.h > expose . You could add a new gdbsupport/gdb_wait.c > file, with the function wrapped in #ifdef __MINGW32__ to keep it simple > and avoid host/target checks in the configure.ac files. Sorry, I don't understand what host/target checks might be needed in configure.ac, can you explain? > We should not rely on signal.h constants for this hook. See gdbarch.sh: > > # Signal translation: translate the GDB's internal signal number into > # the inferior's signal (target's) representation. The implementation > # of this method must be host independent. IOW, don't rely on symbols > # of the NAT_FILE header (the nm-*.h files), the host > # header, or similar headers. > # Return the target signal number if found, or -1 if the GDB internal > # signal number is invalid. > M;int;gdb_signal_to_target;enum gdb_signal signal;signal > > Say you're debugging against a mingw gdbserver from a Linux host. > If you rely on constants here, this function is going to > return the Linux (or whatever the host) numbers instead of the > Windows/mingw numbers. For Linux, we define the LINUX_SIGxxx numbers > in linux-tdep.c, around line 125. The patch should add a similar > enum. So we need to have 2 different sets of explicit signal numbers, one for MinGW64, the other for mingw.org's MinGW (no, they are not identical)? And perhaps one more for Cygwin? Or should we just support the signals common to all 3 environments? And what do we do when the signal numbers in the system's signal.h header change in some future version of MinGW/Cygwin? This sounds like a very fragile arrangement, at least for non-Posix systems where signals are emulated and aren't part of the kernel definitions set in stone. I'm okay with doing a bunch of defines, but it seems to me a maintenance headache in the long run, FWIW. > With this change, the user no longer has access to the original > $_exitcode, for the cases that match one of the known exceptions. > I don't know whether anyone is relying on those, though I wouldn't > be surprised if so. I assume you've pondered about this and consider > that the change is still worth it anyhow. This should at least be > documented. I wonder whether we should provide both the exit > code in $_exitcode and the translated signal number in $_exitsignal, > though that would require more changes. I think this is a micro-optimization that is way in the area of the diminishing returns. I've never seen a program to return an exit status with the high 2 bits set. I'd definitely not recommend to tweak the current assumption in the GDB code that if a program exited due to a signal, its exit code is irrelevant, based on such a theoretical possibility. In most cases, the fact that the inferior got a fatal exception will be noted before it exits anyway. > Related, when windows_status_to_termsig doesn't recognize the > exception number, we end up with GDB_SIGNAL_UNKNOWN, and then > $_exitsignal == -1. I.e., we lose information in that case. Again, > something to ponder about that information loss is OK, or whether > we should do something about it. I don't think we should do anything about it, it's highly theoretical situation I've never seen in real life. And we already lose information in windows-nat.c, when we return GDB_SIGNAL_UNKNOWN for any exception we don't recognize explicitly. In any case, the way this stuff currently works, I see no simple way of returning an arbitrary value of a signal. Maybe we should abandon the idea of doing this in windows-nat.c and win32-low.c, and only translate the exit code in cli-cmds.c for the 'pipe' command? It's much more important in that case (since we don't intercept the signals as we do from the inferior), and most of those complications don't apply there. There's also no backward compatibility problem, since 'pipe' is a new feature in GDB 9, with 2 new convenience variables to hold the exit status and the signal value. WDYT? Thanks.