Re: [Fastboot] [CFT] ELF Relocatable x86 and x86_64 bzImages

[Vivek Goyal]

On Mon, Aug 14, 2006 at 02:10:51PM -0600, Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa@xxxxxxxxx> writes:
> 
> > Vivek Goyal wrote:
> >>>>
> >>> What about once the kernel is booted?
> >> Sorry did not understand the question. Few more lines will help.
> >>
> >
> > Is this field intended to protect any kind of memory during the early boot phase
> > of the kernel proper, or only the decompressor?
> 
> Yes, the field should account for memory usage until the kernel starts
> doing the accounting at run time.
> 
> I'm actually surprised that taking into account the .bss was not enough to
> cover up anything the decompressor was doing.  Usually the kernel's .bss
> is more than the extra 32K or so that the decompressor uses.
>

I think .bss section size will act as a buffer for decompressor only if
.bss is not part of compressed data hence decompressor does not have to
move beyond bss and it can run very well from kernel bss space. 

But somehow on my machine, it looks like that bss is very much part
of raw binary image hence part of compressed data (vmlinux.bin.gz).
memsz exported in bzImage is same as size of raw output binary.

Probably that's the reason that we are stomping other segments in my
case and if my understanding is right then it should happen irrespective
of kernel bss size.

Here I am pasting how kernel vmlinux file program headers look like.
.bss is mapped by first program header along with .text.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000200000 0xffffffff80000000 0x0000000000000000
                 0x0000000000546bf8 0x00000000005dbc28  RWE    200000
  LOAD           0x00000000007dc000 0xffffffff805dc000 0x00000000005dc000
                 0x000000000000ede0 0x000000000000ede0  RW     200000
  LOAD           0x0000000000800000 0xffffffffff600000 0x00000000005eb000
                 0x0000000000000c08 0x0000000000000c08  RWE    200000
  LOAD           0x00000000009ec000 0xffffffff805ec000 0x00000000005ec000
                 0x0000000000044004 0x0000000000044004  RWE    200000
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RWE    8

 Section to Segment mapping:
  Segment Sections...
   00     .text __ex_table .rodata .pci_fixup __ksymtab __ksymtab_gpl
__ksymtab_unused __ksymtab_gpl_future __ksymtab_strings __param
.eh_frame .data .bss
   01     .data.cacheline_aligned .data.read_mostly
   02     .vsyscall_0 .xtime_lock .vxtime .wall_jiffies .sys_tz
.sysctl_vsyscall .xtime .jiffies .vsyscall_1 .vsyscall_2 .vsyscall_3
   03     .data.init_task .data.page_aligned .smp_altinstructions
.smp_locks .smp_altinstr_replacement .init.text .init.data .init.setup
.initcall.init .con_initcall.init .altinstructions .altinstr_replacement
.exit.text .init.ramfs .data.percpu .data_nosave
   04
 
Thanks
Vivek
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/