Re: [Minios-devel] [UNIKRAFT PATCHv4 19/43] plat/kvm: Add link script for Arm64

[Julien Grall <julien.grall@xxxxxxx>]

On 11/07/18 07:56, Wei Chen wrote:
> Hi Julien,
Hi Wei,

> > -----Original Message-----
> > From: Julien Grall <julien.grall@xxxxxxx>
> > Sent: 2018年7月10日 21:13
> > To: Wei Chen <Wei.Chen@xxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
> > simon.kuenzer@xxxxxxxxx
> > Cc: Kaly Xin <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> > Subject: Re: [Minios-devel] [UNIKRAFT PATCHv4 19/43] plat/kvm: Add link script
> > for Arm64
> >
> >
> >
> > On 10/07/18 10:28, Wei Chen wrote:
> > > Hi Julien,
> > Hi Wei,
> >
> > > > -----Original Message-----
> > > > From: Julien Grall <julien.grall@xxxxxxx>
> > > > Sent: 2018年7月9日 4:27
> > > > To: Wei Chen <Wei.Chen@xxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
> > > > simon.kuenzer@xxxxxxxxx
> > > > Cc: Kaly Xin <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
> > > > Subject: Re: [Minios-devel] [UNIKRAFT PATCHv4 19/43] plat/kvm: Add link
> > script
> > > > for Arm64
> > > >
> > > > Hi,
> > > >
> > > > On 07/06/2018 10:03 AM, Wei Chen wrote:
> > > > > This link script is based on x86 version, except following
> > > > > differences:
> > > > > 1. Arm64 needs DTB to parse devices, and QEMU/KVM will revserve
> > > > s/revserve/reserved/
> > > >
> > > > >       the first 64KB of RAM as DTB area. In this case, we add a DTB
> > > > >       section to this link script.
> > > > Do you mind giving a pointer to the QEMU/KVM layout? But then, do we
> > > What did you mean a pointer? A source code link or others?
> > A link to anything describing the layout in QEMU source. This is useful
> > for the reviewer or anyone in the future to understand where your values
> > are taken from.
> Ok, that would be good, I will place a source code link in my code comments
>
> > [...]
> >
> > > > > +       /* Read-write data (uninitialized) */
> > > > The word "uninitialized" is a bit misleading here. In C, this section
> > > > should be Zeroed. So there are not really "unitialized".
> > > Without GCC -fzero-initialized-in-bss, this section in image is not zero,
> > > It is uninitialized. And here, the uninitialized means the objects in
> > > Code are not explicitly initialized to a value. System behavior to
> > > initialize BSS section to zero is not in this scope.
> > Looking at the man, GCC will put variable that are initialized to 0 in
> > BSS unless -fnozero-initialized-in-bss.
> >
> > However, I don't see this option passed to GCC in Unikraft code. Did I
> > miss anything?
> We don't use -fnozero-initialized-in-bss in Unikraft, and I know the bss
> section has been initialized to zero:
> 000000004001f408 <ns_per_tick>:
>      4001f408:  00000000        .word   0x00000000
> But "uninitialized" here means all statically allocated objects that haven't
> been assigned a value in Code will be placed in BSS section. This doesn't mean
> this BSS section is uninitialized.
Well... I guess this is coming from objdump? I have the same in Xen.

In ELF binary, the region will have the size set but no content 
associated. It relies on someone to initialize it to zero. I would guess 
that QEMU is doing that for you when loading the ELF. But I would like 
some confirmation.
However, I still think that "unitialized" is misleading because of some 
values in that are purposefully set to 0. So I would rework that comment 
to avoid some confusion.
Cheers,

--
Julien Grall

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel