[coreboot] r783 - coreboot-v3/arch/x86

ron minnich rminnich at gmail.com
Mon Aug 18 17:59:27 CEST 2008


On Mon, Aug 18, 2008 at 6:03 AM,  <svn at coreboot.org> wrote:
> Author: hailfinger
> Date: 2008-08-18 15:03:43 +0200 (Mon, 18 Aug 2008)
> New Revision: 783
>
> Modified:
>   coreboot-v3/arch/x86/stage1.c
> Log:
> Move otherwise unused stuff inside CONFIG_PAYLOAD_ELF_LOADER.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>
>
> Modified: coreboot-v3/arch/x86/stage1.c
> ===================================================================
> --- coreboot-v3/arch/x86/stage1.c       2008-08-18 11:15:43 UTC (rev 782)
> +++ coreboot-v3/arch/x86/stage1.c       2008-08-18 13:03:43 UTC (rev 783)
> @@ -124,13 +124,12 @@
>  {
>        int ret;
>        struct mem_file archive;
> +       void *entry;
>  #ifdef CONFIG_PAYLOAD_ELF_LOADER
>        struct mem_file result;
>        int elfboot_mem(struct lb_memory *mem, void *where, int size);
> -#endif /* CONFIG_PAYLOAD_ELF_LOADER */
> -       void *entry;
>
> -       /* we can't statically init this hack. */
> +       /* Why can't we statically init this hack? */

If you do this:
struct lb_memory faker = {whatever};

gcc will put the init. data in the elf data segment. This won't play
well with CARI learned this the hard way. What you are doing below is
putting the init data in the code segment by making it part of the
code sequence.

The fix in the following emails with the [0] change to [1] is not only
unnecessary it is actually wrong. The [0] means 'array of length
undefined at compile time'. You just borked that :-) I will comment on
in it the following email :-)

ron




More information about the coreboot mailing list