From: Siddhesh Poyarekar <siddhesh@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Expand bitpos to LONGEST to allow access to large offsets within a struct
Date: Mon, 05 Mar 2012 06:34:00 -0000 [thread overview]
Message-ID: <20120305063542.GA30196@spoyarek.pnq.redhat.com> (raw)
In-Reply-To: <20120301224428.GA30631@host2.jankratochvil.net>
On Thu, Mar 01, 2012 at 11:44:28PM +0100, Jan Kratochvil wrote:
> But to make this patch really working for struct offsets (and not just enum's)
> one needs to also extend the type->length width. I am sorry but it will be
> a big patch.
OK, will work on this.
> splint gives nice advices, thanks for the idea. I think it would not give a
> warning if there is incorrectly used 'long' instead of LONGEST'.
I think it should give this warning on ia32, since there is a storage
size mismatch there. That said, I need to test on 32-bit the next time
too.
> > - ((TYPE_UNSIGNED (type) ? ax_zero_ext : ax_ext) (ax, end - start));
> > + ((TYPE_UNSIGNED (type) ? ax_zero_ext : ax_ext) (ax, (int)(end - start)));
>
> Here I think ax_zero_ext and ax_ext should use LONGEST instead of the cast.
> (OK, one may argue a bit about it.)
>
The reason I cast it down to INT is because the eventual call to
generic_ext() requires N to be between 0 and 255. But I guess we might
want to keep the value intact to catch any internal bugs that may
trigger this?
Thanks for your very detailed review. I'll fix up the patch and also
expand type->length.
--
Siddhesh
next prev parent reply other threads:[~2012-03-05 6:34 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-20 14:53 Siddhesh Poyarekar
2012-02-21 20:46 ` Tom Tromey
2012-02-22 7:44 ` Siddhesh Poyarekar
2012-02-29 13:55 ` Siddhesh Poyarekar
2012-02-29 13:59 ` Siddhesh Poyarekar
2012-03-01 22:45 ` Jan Kratochvil
2012-03-05 6:34 ` Siddhesh Poyarekar [this message]
2012-03-05 8:05 ` Jan Kratochvil
2012-03-21 10:06 ` [PATCH] Allow 64-bit enum values Siddhesh Poyarekar
2012-03-27 17:00 ` Jan Kratochvil
2012-03-28 4:19 ` Siddhesh Poyarekar
2012-03-30 16:15 ` Jan Kratochvil
2012-04-17 14:01 ` Jan Kratochvil
2012-04-18 2:53 ` Siddhesh Poyarekar
2012-04-18 6:58 ` [commit] " Jan Kratochvil
2012-04-18 7:06 ` [ChangeLog commit] " Jan Kratochvil
2012-04-19 16:58 ` [commit] " Ulrich Weigand
2012-04-20 4:23 ` Siddhesh Poyarekar
2012-04-20 7:50 ` [obv] Fix python-2.4 compilation compat. [Re: [commit] [PATCH] Allow 64-bit enum values] Jan Kratochvil
2012-04-20 19:00 ` Tom Tromey
2012-03-28 16:55 ` [PATCH] Allow 64-bit enum values Tom Tromey
2012-03-29 10:56 ` Siddhesh Poyarekar
2012-04-17 13:11 ` [commit] Support 64-bit constants/enums on 32-bit host [Re: [PATCH] Allow 64-bit enum values] Jan Kratochvil
2012-04-17 13:16 ` [patch!] " Jan Kratochvil
2012-04-17 14:33 ` [patch] " Jan Kratochvil
2012-04-17 15:59 ` Tom Tromey
2012-04-17 15:42 ` Jan Kratochvil
2012-04-17 15:52 ` Tom Tromey
2012-04-17 14:33 ` [commit] " Tom Tromey
2012-04-17 14:55 ` Jan Kratochvil
2012-04-17 15:18 ` Tom Tromey
2012-04-17 15:32 ` Jan Kratochvil
2012-04-17 19:32 ` Jan Kratochvil
2012-04-17 20:51 ` Tom Tromey
2012-04-18 7:01 ` [real commit] " Jan Kratochvil
2012-02-21 21:39 ` [PATCH] Expand bitpos to LONGEST to allow access to large offsets within a struct Jan Kratochvil
2012-05-04 13:10 ` [PATCH v2] Expand bitpos and type.length to LONGEST and ULONGEST Siddhesh Poyarekar
2012-05-15 9:46 ` ping: " Siddhesh Poyarekar
2012-05-15 9:49 ` Jan Kratochvil
2012-05-15 10:02 ` Siddhesh Poyarekar
2012-05-15 20:07 ` Jan Kratochvil
2012-05-16 3:50 ` Siddhesh Poyarekar
2012-05-16 7:19 ` Jan Kratochvil
2012-05-16 7:41 ` Siddhesh Poyarekar
2012-05-20 15:43 ` Doug Evans
2012-05-20 20:24 ` Jan Kratochvil
2012-05-20 20:28 ` Doug Evans
2012-05-23 13:52 ` Siddhesh Poyarekar
2012-05-23 17:46 ` Jan Kratochvil
2012-05-24 1:36 ` Siddhesh Poyarekar
2012-05-24 15:01 ` Jan Kratochvil
2012-05-31 18:15 ` [PATCH v3] " Siddhesh Poyarekar
2012-06-05 22:27 ` Jan Kratochvil
2012-06-06 18:23 ` Siddhesh Poyarekar
2012-06-06 21:34 ` Jan Kratochvil
2012-06-08 14:16 ` Jan Kratochvil
2012-06-08 15:27 ` Jan Kratochvil
2012-06-11 12:53 ` Siddhesh Poyarekar
2012-06-11 13:00 ` Jan Kratochvil
2012-06-11 18:33 ` Siddhesh Poyarekar
2012-06-12 9:56 ` Jan Kratochvil
2012-06-12 14:35 ` Jan Kratochvil
2012-06-18 10:31 ` [1/2][PATCH " Siddhesh Poyarekar
2012-06-20 15:47 ` Jan Kratochvil
2012-06-20 16:32 ` Siddhesh Poyarekar
2012-06-20 17:25 ` Jan Kratochvil
2012-06-23 1:59 ` Siddhesh Poyarekar
2012-06-18 10:31 ` [2/2][PATCH " Siddhesh Poyarekar
2012-05-31 6:39 ` [PATCH v2] " Siddhesh Poyarekar
2012-05-31 9:24 ` 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=20120305063542.GA30196@spoyarek.pnq.redhat.com \
--to=siddhesh@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=tromey@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