On Wed, Jan 17, 2024 at 12:39:06PM +0530, Mukesh Kumar Chaurasiya wrote:
> On 11/30/23 00:45, Daniel Kiper wrote:
> > On Mon, Nov 27, 2023 at 06:07:42PM +0530, Mukesh Kumar Chaurasiya wrote:
> > > Signed-off-by: Mukesh Kumar Chaurasiya <mchau...@linux.ibm.com>
> > > ---
> > > grub-core/disk/ieee1275/ofdisk.c | 11 ++++++++---
> > > 1 file changed, 8 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/grub-core/disk/ieee1275/ofdisk.c
> > > b/grub-core/disk/ieee1275/ofdisk.c
> > > index c6cba0c8a..9cd8898f1 100644
> > > --- a/grub-core/disk/ieee1275/ofdisk.c
> > > +++ b/grub-core/disk/ieee1275/ofdisk.c
> > > @@ -222,8 +222,12 @@ dev_iterate (const struct grub_ieee1275_devalias
> > > *alias)
> > > grub_ieee1275_cell_t table;
> > > }
> > > args;
> > > + struct lun_buf {
> > > + grub_uint64_t *buf_addr;
> > This will not work on 32-bit architectures.
>
> Umm...
>
> well i checked this and the definition for 32bit and 64bit are same. So the
I am not entirely sure what you mean by "the same" here.
> structure part should be fine.
>
> + ptr =(grub_uint64_t*)(grub_addr_t) tbl[i].buf_addr;
> and this should handle the 32bit arch in terms of address.
> for rest i'll send out a new version of patch
The problem is with the *buf_addr pointer. Its size on 32-bit platform
is 32-bit. So, on 32-bit platform you will have struct with 32-bit member and
64-bit member following it. This is not what you expect. The buf_addr/buf_size
table has each entry with two 64-bit members. Am I missing something?
Daniel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
