Subject: head.S and init_task.c vs addinitrd

From: Guido Guenther <[email-masked]>
Date: Sat, 13 Apr 2002 21:28:11 +0200

Hi,
short: 
The attached patch modifies head.S/init_task.c to restore the old habit
of merging all sections(besides .reginfo) into one segment which lets
elf2ecoff/addinitrd work again.

long:
some of the recent head.S/init_task.c changes break addinitrd. In 2.4.16
we had two segments which allowed elf2ecoff to put everything (besides
bss) into one text section (dropping REGINFO) in the ecoff image leaving
the data section emtpy. Addinitrd then later merged the initial ramdisk
into that empty data section.

ELF kernel:
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  REGINFO        0x1c2ae0 0x881c3ae0 0x881c3ae0 0x00018 0x00018 R   0x4
  LOAD           0x001000 0x88002000 0x88002000 0x1e8000 0x1ff560 RWE 0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .reginfo 
   01     .text .fixup .kstrtab __ex_table __ksymtab .text.init .data.init .setup.init .initcall.init .data.cacheline_aligned .reginfo .data .bss

ECOFF kernel:
Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         001e8000  0000000088002000  0000000088002000  000000d0  2**4
                  CONTENTS, ALLOC, LOAD, CODE
  1 .data         00000000  00000000881ea000  00000000881ea000  001e80d0  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .bss          00017560  00000000881ea000  00000000881ea000  001e80d0  2**4
                  CONTENTS, ALLOC, NEVER_LOAD

Now as of 2.4.17+ we have three segments described in the program
header:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  REGINFO        0x1c4ae0 0x881c5ae0 0x881c5ae0 0x00018 0x00018 R   0x4
  LOAD           0x001000 0x88002000 0x88002000 0x1ab140 0x1ab140 R E 0x1000
  LOAD           0x1ad000 0x881ae000 0x881ae000 0x43000 0x5a560 RWE 0x1000

 Section to Segment mapping:
  Segment Sections...
   00     .reginfo 
   01     .text .fixup .kstrtab __ex_table __ksymtab 
   02     .data.init_task .text.init .data.init .setup.init .initcall.init .data.cacheline_aligned .reginfo .data .bss

so there's no emtpy section left in the ecoff image for the initial
ramdisk. What was the reasoning for the above change? And why exactly
does this change cause a splitting into data and text segment where as
of 2.4.16 there was only a "data" segment?
Regards,
 -- Guido
diff --exclude=*.orig --exclude=.* -Naur ../../kernel-source-2.4.17/arch/mips/kernel/head.S arch/mips/kernel/head.S
--- ../../kernel-source-2.4.17/arch/mips/kernel/head.S	Thu Mar  7 22:49:57 2002
+++ arch/mips/kernel/head.S	Sat Apr 13 14:09:31 2002
@@ -178,10 +178,15 @@
 	.type	\name, @object
 	.endm
 
-	.data
-	.align	12
+	.text
 
 	page	swapper_pg_dir, PGD_ORDER
 	page	empty_bad_page, 0
 	page	empty_bad_page_table, 0
 	page	invalid_pte_table, 0
+
+/*
+ * Align to 8kb boundary for init_task_union which follows in the
+ * .text segment.
+ */
+	.align	13
diff --exclude=*.orig --exclude=.* -Naur ../../kernel-source-2.4.17/arch/mips/kernel/init_task.c arch/mips/kernel/init_task.c
--- ../../kernel-source-2.4.17/arch/mips/kernel/init_task.c	Thu Mar  7 22:49:57 2002
+++ arch/mips/kernel/init_task.c	Sat Apr 13 14:09:31 2002
@@ -20,5 +20,5 @@
  * The things we do for performance..
  */
 union task_union init_task_union
-	__attribute__((__section__(".data.init_task"))) =
+	__attribute__((__section__(".text"))) =
 		{ INIT_TASK(init_task_union.task) };

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 15 Apr 2002 14:49:11 +0200 (MET DST)

> into that empty data section.

 Hmm, isn't that broken?  I believe an initial RAM disk should be added to
an ELF image, before converting it to ECOFF.  Not everyone uses ECOFF and
ELF is the "canonical" executable format for Linux.  Everything else is a
derivative.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Guido Guenther <[email-masked]>
Date: Mon, 15 Apr 2002 15:43:15 +0200

> ELF is the "canonical" executable format for Linux.  Everything else is a
But we currently don't support relinking the ELF kernel to add a ramdisk,
do we [1]? Elf2ecoff/addinitrd is the only way I know of to achieve this
and I still don't understand why the recent init_task.c/head.S changes
where necessary which broke this.
 -- Guido

[1] I know that one can link a ramdisk into the ELF image but this
ramdisk hat to be available at kernel compile time which is not an option in
many situations(e.g. Debian "boot-floppies").

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 15 Apr 2002 16:09:41 +0200 (MET DST)

> But we currently don't support relinking the ELF kernel to add a ramdisk,

 I don't know.  We are going to have to if the BOOTP/NFS-root code gets
removed, which will supposedly happen quite soon.

> where necessary which broke this.

 Maybe because that's an ugly hack (as I can see from your description).

> many situations(e.g. Debian "boot-floppies").

 It depends on how a kernel gets built.  If we add "-r" to the current
final link we'll get "vmlinux.o" that is a complete, self-contained
kernel, that may be linked against a RAM-disk (or just relinked alone) 
without a problem.  That's actually a generic solution and certainly
something like this will likely have to get implemented as soon as a
RAM-disk gets mandatory for block-device-less ;-) configurations. 

  Maciej

---

From: Guido Guenther <[email-masked]>
Date: Mon, 15 Apr 2002 18:17:43 +0200

>  Maybe because that's an ugly hack (as I can see from your description).
Are you telling me the only reason for the changes in init_task.c/head.S
were made to break the elf2ecoff/addinitrd "hack"? Where exactly was
there a hack in head.S/init_task.c. Please point me to the line of code
since I don't understand enough about the kernel to see it.

> RAM-disk gets mandatory for block-device-less ;-) configurations. 
That's 2.5 stuff. We should not break expected behavior in 2.4.
 -- Guido

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 15 Apr 2002 20:13:42 +0200 (MET DST)

> since I don't understand enough about the kernel to see it.

 I meant it stopped working because it is an ugly hack.  It is too fragile
to work in all cases. 

> That's 2.5 stuff. We should not break expected behavior in 2.4.

 Agreed.

---

From: Guido Guenther <[email-masked]>
Date: Tue, 16 Apr 2002 11:14:49 +0200

>  I meant it stopped working because it is an ugly hack.  It is too
I admit it's fragile but I'm still puzzled why the changes broke it and
if we can revert those changes on the linux_2_4 branch.
 -- Guido