Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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