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: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Mon, 5 Mar 2012 12:05:43 +0530
- 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>
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