From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Siddhesh Poyarekar <siddhesh@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: bitpos expansion patches summary
Date: Fri, 10 Aug 2012 07:51:00 -0000 [thread overview]
Message-ID: <20120810075056.GA1974@host2.jankratochvil.net> (raw)
In-Reply-To: <20120810071338.15d68ab0@spoyarek>
On Fri, 10 Aug 2012 03:43:38 +0200, Siddhesh Poyarekar wrote:
> On Thu, 9 Aug 2012 22:03:56 +0200, Jan wrote:
> > + if (!TYPE_LENGTH_FITS_SIZET (type))
> > + error (_("Target object too large for host GDB memory."));
> > +
> > +Please print the sizes. Also this message is present at multiple
> > places so +maybe rather make a function for unconditionally printing
> > the error? +
>
> Could you please give an example of this? I didn't think that there are
> any such checks in the source yet.
if (accumulate_size < 0)
error (_("Total size of arguments too large for host GDB memory."));
It also should print the sizes, in some cases GDB would print the first error
above, in other cases the second error, I do not think there is a difference.
> > +Make it TYPE_LENGTH_FITS_SIZE_T, please. And I think this macro is
> > not needed, +inline it. (It does not access internal fields of the
> > type structures.) +
>
> I had kept it for possible future need if someone wants to only check
> if a type fits in and not throw an error. I will inline it.
OK, I understand now the goal. But GDB does not accept additional code which
is useful only with future extension.
> > +And (a) check it already for ssize_t. Because the code is not safe
> > enough to +properly handle unsigned sizes everywhere without
> > overflows. (b) Make there +some reserve, anything close to ssize_t
> > will never get successfully xmalloc-ed +anyway. Some maximum size
> > could be: ((size_t) -1) / 4. Depending on SSIZE_MAX +may not be
> > compatible enough I guess. +
>
> I had thought of that, but I figured that instead of guessing a value,
> I would be better off only doing the size_t check (i.e. code sanity) and
> leave the question of whether a type gets successfully malloc'd or not
> to the OS.
The problem is if you futher add something to the value it overflows, xmalloc
will then get few bytes, which succeeds, but GDB behavior is wrong then.
You have correctly put in alpha-tdep.c the new check for such case:
/* Check for overflow. */
if (accumulate_size < 0)
error (_("Total size of arguments too large for host GDB memory."));
But I have doubts one can catch such overflows across the whole GDB codebase,
so I see some 'safe enough margin' for overflows to be more universal check
for it.
> For ssize_t, I could add an extra boolean argument to
> type_fits_size_t_or_error that indicates whether the type is signed or
> not.
We discussed before that the larger size of unsigned types vs. signed types is
not useful. GDB will never successfully allocate more than 2GB on 32-bit host
(size_t max larger than ssize_t). And it does not make sense to consider
anyhow sizes above 9 quintillion (ULONGEST max larger than LONGEST on any host
or size_t larger than ssize_t on 64-bit hosts)
Thanks,
Jan
next prev parent reply other threads:[~2012-08-10 7:51 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-04 19:24 Siddhesh Poyarekar
2012-08-07 14:39 ` Jan Kratochvil
2012-08-07 15:10 ` Siddhesh Poyarekar
2012-08-07 15:48 ` Siddhesh Poyarekar
2012-08-08 22:43 ` Jan Kratochvil
2012-08-08 22:50 ` Jan Kratochvil
2012-08-09 2:04 ` Siddhesh Poyarekar
2012-08-10 1:28 ` Siddhesh Poyarekar
2012-08-17 9:35 ` Siddhesh Poyarekar
2012-08-09 20:04 ` Jan Kratochvil
2012-08-10 1:44 ` Siddhesh Poyarekar
2012-08-10 7:51 ` Jan Kratochvil [this message]
2012-08-10 7:58 ` Siddhesh Poyarekar
2012-08-12 17:57 ` Jan Kratochvil
2012-08-13 2:52 ` Siddhesh Poyarekar
2012-08-13 13:49 ` Jan Kratochvil
2012-08-13 14:04 ` Siddhesh Poyarekar
2012-08-13 14:12 ` Jan Kratochvil
2012-08-13 14:24 ` Siddhesh Poyarekar
2012-08-17 9:35 ` [PATCH 4/3] bitpos: Expand parameters of watchpoint functions Siddhesh Poyarekar
2012-08-19 16:42 ` bitpos expansion patches summary Jan Kratochvil
2012-08-21 6:51 ` Siddhesh Poyarekar
2012-08-26 18:21 ` Jan Kratochvil
2012-08-27 8:10 ` Siddhesh Poyarekar
2012-08-27 14:02 ` Jan Kratochvil
2012-09-02 18:15 ` Jan Kratochvil
2012-09-07 10:52 ` Siddhesh Poyarekar
2012-09-11 19:04 ` Jan Kratochvil
2012-09-11 19:26 ` Tom Tromey
2012-09-11 19:37 ` Jan Kratochvil
2012-09-13 18:45 ` Jan Kratochvil
2012-09-13 16:48 ` Jan Kratochvil
2012-09-14 6:20 ` Siddhesh Poyarekar
2012-09-04 15:03 ` Jan Kratochvil
2012-09-04 15:09 ` Siddhesh Poyarekar
2012-09-07 11:10 ` Siddhesh Poyarekar
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=20120810075056.GA1974@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=siddhesh@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