From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: brobecker@adacore.com
Cc: teawater@gmail.com, gdb@sourceware.org, msnyder@vmware.com
Subject: Re: [gdb-7.0 release] 2009-09-02 status and proposed plan
Date: Sat, 05 Sep 2009 08:13:00 -0000 [thread overview]
Message-ID: <200909050812.n858CrY4005087@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <20090905002520.GA19729@adacore.com> (message from Joel Brobecker on Fri, 4 Sep 2009 17:25:20 -0700)
> Date: Fri, 4 Sep 2009 17:25:20 -0700
> From: Joel Brobecker <brobecker@adacore.com>
>
> Hui,
>
> > I had post a patch for it. It still in discussion.
> > http://sourceware.org/ml/gdb-patches/2009-08/msg00574.html
>
> As far as I can tell, you received some feedback from one of the
> maintainers (Mark Kettenis) about your patch:
>
> http://sourceware.org/ml/gdb-patches/2009-08/msg00584.html
>
> I also looked at your patch before looking at the replies, and I had
> the same comments as Jiang and Mark. The casts in this raised a red
> flag, and I don't see why we should need them.
>
> Would it make sense to define a type syscall_t that's either an int
> or an unsigned int, and use that consistently throughout? Otherwise,
> another simpler option would be to just use either int or unsigned int
> without using a typedef.
I'm not a big fan of typedefs like this. They hide the signedness of
the type, which makes it more likely we'll end up with signed ->
unsigned conversions again or messed up range checks.
Unless people are aware of an operating system that uses negative
numbers for system calls, I don't think it matters very much whether
we use a signed or an unsigned type. However, we have to pick one and
use it consistently. We fail to do that for line numbers, and as a
result we still have bugs in our code.
> In the meantime, I think you can get away from this all by using
> regcache_raw_write_signed. Read the syscall ID as a signed number,
> all should be fine. I'm attaching a patch that fixes the build
> issue an illustrates this suggestion. Can you please give it a
> test and resubmit if it works for you?
This would be almost ok, but you'll need a check that syscall_num
isn't < 0 as well.
> --GvXjxJ+pjyke8COw
> Content-Type: text/x-diff; charset=us-ascii
> Content-Disposition: attachment; filename="syscall-cygwin-64bit.diff"
>
> Index: i386-linux-tdep.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/i386-linux-tdep.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 i386-linux-tdep.c
> --- i386-linux-tdep.c 10 Aug 2009 03:04:44 -0000 1.66
> +++ i386-linux-tdep.c 5 Sep 2009 00:24:25 -0000
> @@ -367,18 +367,19 @@ static int
> i386_linux_intx80_sysenter_record (struct regcache *regcache)
> {
> int ret;
> - uint32_t tmpu32;
> + LONGEST syscall_num;
>
> - regcache_raw_read (regcache, I386_EAX_REGNUM, (gdb_byte *) &tmpu32);
> + regcache_raw_read_signed (regcache, I386_EAX_REGNUM, &syscall_num);
>
> - if (tmpu32 > 499)
> + if (syscall_num > 499)
> {
> - printf_unfiltered (_("Process record and replay target doesn't "
> - "support syscall number %u\n"), tmpu32);
> + printf_unfiltered (_("Process record and replay target does not "
> + "support syscall number %s\n"),
> + plongest (syscall_num));
> return -1;
> }
>
> - ret = record_linux_system_call (tmpu32, regcache,
> + ret = record_linux_system_call (syscall_num, regcache,
> &i386_linux_record_tdep);
> if (ret)
> return ret;
>
> --GvXjxJ+pjyke8COw--
>
next prev parent reply other threads:[~2009-09-05 8:13 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-02 16:44 Joel Brobecker
2009-09-02 17:09 ` Jack Howarth
2009-09-02 17:18 ` Joel Brobecker
2009-09-03 8:58 ` Tristan Gingold
2009-09-02 19:28 ` Tom Tromey
2009-09-03 3:18 ` Eli Zaretskii
2009-09-03 3:30 ` Hui Zhu
2009-09-04 15:48 ` Sérgio Durigan Júnior
2009-09-03 19:28 ` Joel Brobecker
2009-09-03 19:53 ` Tom Tromey
2009-09-03 21:35 ` Joel Brobecker
2009-09-04 15:44 ` Tom Tromey
2009-09-04 21:34 ` Sérgio Durigan Júnior
2009-09-04 21:37 ` Sérgio Durigan Júnior
2009-09-04 21:37 ` Sérgio Durigan Júnior
2009-09-03 19:26 ` Joel Brobecker
2009-09-03 20:12 ` Tom Tromey
2009-09-03 20:39 ` Matt Rice
2009-09-03 21:43 ` Joel Brobecker
2009-09-04 15:36 ` Doug Evans
2009-09-03 2:05 ` Hui Zhu
2009-09-03 19:31 ` Joel Brobecker
2009-09-05 0:25 ` Joel Brobecker
2009-09-05 8:13 ` Mark Kettenis [this message]
2009-09-05 8:24 ` Jonas Maebe
2009-09-05 15:58 ` Eli Zaretskii
2009-09-03 4:06 ` Doug Evans
2009-09-03 15:54 ` Paul Pluzhnikov
2009-09-03 16:00 ` Pierre Muller
2009-09-03 16:11 ` Paul Pluzhnikov
2009-09-04 10:20 ` Pierre Muller
2009-09-04 15:07 ` Paul Pluzhnikov
2009-09-07 14:58 ` Pierre Muller
[not found] ` <8ac60eac0909072137g41f7b1f8q2e9e1e6d6d161fc5@mail.gmail.com>
[not found] ` <000301ca309f$35d475d0$a17d6170$@u-strasbg.fr>
2009-09-08 20:41 ` Paul Pluzhnikov
2009-09-03 19:33 ` Joel Brobecker
2009-09-04 15:25 ` Paul Pluzhnikov
2009-09-04 17:59 ` Paul Pluzhnikov
2009-09-04 18:03 ` Doug Evans
2009-09-05 0:29 ` Joel Brobecker
2009-09-14 17:43 ` Paul Pluzhnikov
2009-09-14 17:52 ` Joel Brobecker
2009-09-14 18:20 ` Paul Pluzhnikov
2009-09-15 20:28 ` Paul Pluzhnikov
2009-09-03 18:34 ` Anirban Sinha
2009-09-04 23:07 ` Joel Brobecker
2009-09-16 6:47 ` Hui Zhu
[not found] ` <F7CE05678329534C957159168FA70DEC5153684DC5@EUSAACMS0703.eamcs.ericsson.se>
2009-09-17 1:02 ` Joel Brobecker
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=200909050812.n858CrY4005087@brahms.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
--cc=msnyder@vmware.com \
--cc=teawater@gmail.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