This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Expand bitpos to LONGEST to allow access to large offsets within a struct
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 5 Mar 2012 09:05:12 +0100
- Subject: Re: [PATCH] Expand bitpos to LONGEST to allow access to large offsets within a struct
- References: <20120220132724.GB4753@spoyarek.pnq.redhat.com> <87d397syts.fsf@fleche.redhat.com> <20120229135148.GA32128@spoyarek.pnq.redhat.com> <20120301224428.GA30631@host2.jankratochvil.net> <20120305063542.GA30196@spoyarek.pnq.redhat.com>
On Mon, 05 Mar 2012 07:35:43 +0100, Siddhesh Poyarekar wrote:
> On Thu, Mar 01, 2012 at 11:44:28PM +0100, Jan Kratochvil wrote:
> > 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.
True, good idea.
> > > - ((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?
Yes, I meant that.
> Thanks for your very detailed review. I'll fix up the patch and also
> expand type->length.
Maybe you can keep that patch as a separate one; but I do not mind much.
Thanks,
Jan