public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH 03/10] sim/ppc: initialize a memory buffer in all cases
Date: Wed, 19 Oct 2022 16:24:42 +0100	[thread overview]
Message-ID: <0bd7df35b8c709a72d6f2a0900e60fa12727779e.1666192979.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1666192979.git.aburgess@redhat.com>

In the ppc simulator's do_fstat function, which provides the fstat
call for the simulator, if the fstat is going to fail then we current
write an uninitialized buffer into the inferior.

In theory, I think this is fine, we also write the error status into
the simulated target, so, given that the fstat has failed, the target
shouldn't be relying on the buffer contents.

However, writing an uninitialized buffer means we might leak simulator
private data into the simulated target, which is probably a bad
thing.  Plus it probably makes life easier if something consistent,
like all zeros, is written rather than random junk, that might look
like a successful call.

So, in this commit, I clear the stat buffer to zero before writing it
into the simulated target, if the fstat call is not run (due to a bad
file descriptor).

Another option would be to just not write the buffer into the
inferior (rather than zeroing it, and writing all zeros).  This would
solve the problem of copying simulator data into the target, but I
think the all zeros will make debugging things in the simulator
easier.
---
 sim/ppc/emul_netbsd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sim/ppc/emul_netbsd.c b/sim/ppc/emul_netbsd.c
index 322b584a3f1..f5fa8499bde 100644
--- a/sim/ppc/emul_netbsd.c
+++ b/sim/ppc/emul_netbsd.c
@@ -888,6 +888,8 @@ do_fstat(os_emul_data *emul,
   status = fdbad (fd);
   if (status == 0)
     status = fstat(fd, &buf);
+  else
+    memset (&buf, 0, sizeof (buf));
   emul_write_status(processor, status, errno);
   write_stat(stat_buf_addr, buf, processor, cia);
 }
-- 
2.25.4


  parent reply	other threads:[~2022-10-19 15:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19 15:24 [PATCH 00/10] Building the sim/ tree with clang Andrew Burgess
2022-10-19 15:24 ` [PATCH 01/10] sim/sh: use fabs instead of abs Andrew Burgess
2022-10-23 13:53   ` Mike Frysinger
2022-10-24 16:05     ` Andrew Burgess
2022-10-19 15:24 ` [PATCH 02/10] sim/ppc: don't try to print an uninitialized variable Andrew Burgess
2022-10-23 13:51   ` Mike Frysinger
2022-10-24 16:05     ` Andrew Burgess
2022-10-19 15:24 ` Andrew Burgess [this message]
2022-10-23 13:50   ` [PATCH 03/10] sim/ppc: initialize a memory buffer in all cases Mike Frysinger
2022-10-24 16:25     ` Andrew Burgess
2022-10-19 15:24 ` [PATCH 04/10] sim/ppc: don't pass uninitialized value to semctl for GETVAL calls Andrew Burgess
2022-10-23 14:01   ` Mike Frysinger
2022-10-19 15:24 ` [PATCH 05/10] sim/ppc: fix for operator precedence warning from clang Andrew Burgess
2022-10-23 13:55   ` Mike Frysinger
2022-10-24 16:26     ` Andrew Burgess
2022-10-19 15:24 ` [PATCH 06/10] sim/aarch64: remove two unused functions Andrew Burgess
2022-10-23 13:55   ` Mike Frysinger
2022-10-24 16:26     ` Andrew Burgess
2022-10-19 15:24 ` [PATCH 07/10] sim/rx: delete an unused function Andrew Burgess
2022-10-23 13:54   ` Mike Frysinger
2022-10-19 15:24 ` [PATCH 08/10] sim/h8300: avoid self assignment Andrew Burgess
2022-10-23 13:52   ` Mike Frysinger
2022-10-24 16:26     ` Andrew Burgess
2022-10-19 15:24 ` [PATCH 09/10] sim/lm32: fix some missing function declaration warnings Andrew Burgess
2022-10-23 14:13   ` Mike Frysinger
2022-10-24 16:27     ` Andrew Burgess
2022-10-19 15:24 ` [PATCH 10/10] sim/cris/m32c/sh: disable use of -Werror Andrew Burgess
2022-10-20  3:53   ` Tsukasa OI
2022-10-21 15:58     ` Andrew Burgess
2022-10-24  8:58       ` Tsukasa OI
2022-10-24 16:23         ` Andrew Burgess
2022-10-20 18:36   ` Tom Tromey
2022-10-23 14:17   ` Mike Frysinger
2022-10-20 18:36 ` [PATCH 00/10] Building the sim/ tree with clang Tom Tromey

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=0bd7df35b8c709a72d6f2a0900e60fa12727779e.1666192979.git.aburgess@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /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).