All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-04-30 15:12 ` Eric W. Biederman
  0 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-04-30 15:12 UTC (permalink / raw)
  To: Andi Kleen, Andrew Morton
  Cc: Jurriaan, Helge Hafting, linux-kernel, Horms, Kexec Mailing List


Currently because vmlinux does not reflect that the kernel is relocatable
we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
c program to do what we cannot do with a linker script set the elf header
type to ET_DYN.

Since last time I have fixed the type to be in my code ET_DYN (oops),
and verified this works with kexec.  I realized while testing that we
don't have anyway of identifying a kernel vmlinux as linux so we
probably want to add an ELF note but that will be another patch.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86_64/Kconfig  |    4 +++
 arch/x86_64/Makefile |   10 +++++++
 scripts/Makefile     |   11 ++++---
 scripts/mketrel.c    |   70 ++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 90 insertions(+), 5 deletions(-)
 create mode 100644 scripts/mketrel.c

diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index b00adb9..95949c3 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64
 	bool
 	default n
 
+config ELF_RELOCATABLE
+	bool
+	default y
+
 source "init/Kconfig"
 
 
diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile
index a81a84a..7c0434c 100644
--- a/arch/x86_64/Makefile
+++ b/arch/x86_64/Makefile
@@ -125,6 +125,16 @@ define archhelp
   echo  '  isoimage     - Create a boot CD-ROM image'
 endef
 
+ifeq ($(CONFIG_RELOCATABLE),y)
+define cmd_vmlinux__
+      $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
+      -T $(vmlinux-lds) $(vmlinux-init)		\
+      --start-group $(vmlinux-main) --end-group	\
+      $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \
+      && scripts/mketrel $@
+endef
+endif
+
 CLEAN_FILES += arch/$(ARCH)/boot/fdimage \
 	       arch/$(ARCH)/boot/image.iso \
 	       arch/$(ARCH)/boot/mtools.conf
diff --git a/scripts/Makefile b/scripts/Makefile
index 1c73c5a..ddba550 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -7,11 +7,12 @@
 # conmakehash:   Create chartable
 # conmakehash:	 Create arrays for initializing the kernel console tables
 
-hostprogs-$(CONFIG_KALLSYMS)     += kallsyms
-hostprogs-$(CONFIG_LOGO)         += pnmtologo
-hostprogs-$(CONFIG_VT)           += conmakehash
-hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash
-hostprogs-$(CONFIG_IKCONFIG)     += bin2c
+hostprogs-$(CONFIG_KALLSYMS)        += kallsyms
+hostprogs-$(CONFIG_LOGO)            += pnmtologo
+hostprogs-$(CONFIG_VT)              += conmakehash
+hostprogs-$(CONFIG_PROM_CONSOLE)    += conmakehash
+hostprogs-$(CONFIG_IKCONFIG)        += bin2c
+hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel
 
 always		:= $(hostprogs-y) $(hostprogs-m)
 
diff --git a/scripts/mketrel.c b/scripts/mketrel.c
new file mode 100644
index 0000000..aa0408a
--- /dev/null
+++ b/scripts/mketrel.c
@@ -0,0 +1,70 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <elf.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+#include <stdarg.h>
+#include <stdlib.h>
+
+static int fd;
+unsigned char e_ident[EI_NIDENT];
+
+void die(const char * str, ...)
+{
+	va_list args;
+	va_start(args, str);
+	vfprintf(stderr, str, args);
+	fputc('\n', stderr);
+	exit(1);
+}
+
+void file_open(const char *name)
+{
+	if ((fd = open(name, O_RDWR, 0)) < 0)
+		die("Unable to open `%s': %m", name);
+}
+
+static void mketrel(void)
+{
+	unsigned char e_type[2];
+	if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident))
+		die("Cannot read ELF header: %s\n", strerror(errno));
+
+	if (memcmp(e_ident, ELFMAG, 4) != 0)
+		die("No ELF magic\n");
+
+	if ((e_ident[EI_CLASS] != ELFCLASS64) &&
+	    (e_ident[EI_CLASS] != ELFCLASS32))
+		die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]);
+	
+	if ((e_ident[EI_DATA] != ELFDATA2LSB) &&
+	    (e_ident[EI_DATA] != ELFDATA2MSB))
+		die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]);
+
+	if (e_ident[EI_VERSION] != EV_CURRENT)
+		die("Unknown ELF version: %d\n", e_ident[EI_VERSION]);
+
+	if (e_ident[EI_DATA] == ELFDATA2LSB) {
+		e_type[0] = ET_DYN & 0xff;
+		e_type[1] = ET_DYN >> 8;
+	} else {
+		e_type[1] = ET_DYN & 0xff;
+		e_type[0] = ET_DYN >> 8;
+	}
+
+	if (write(fd, &e_type, sizeof(e_type)) != sizeof(e_type))
+		die("Cannot write ELF type: %s\n", strerror(errno));
+}
+
+int main(int argc, char **argv)
+{
+	if (argc != 2)
+		die("Usage: mketrel: vmlinux");
+	file_open(argv[1]);
+	mketrel();
+	close(fd);
+	return 0;
+}
-- 
1.5.1.1.181.g2de0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-04-30 15:12 ` Eric W. Biederman
  0 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-04-30 15:12 UTC (permalink / raw)
  To: Andi Kleen, Andrew Morton
  Cc: Helge Hafting, Horms, Kexec Mailing List, Jurriaan, linux-kernel


Currently because vmlinux does not reflect that the kernel is relocatable
we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
c program to do what we cannot do with a linker script set the elf header
type to ET_DYN.

Since last time I have fixed the type to be in my code ET_DYN (oops),
and verified this works with kexec.  I realized while testing that we
don't have anyway of identifying a kernel vmlinux as linux so we
probably want to add an ELF note but that will be another patch.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86_64/Kconfig  |    4 +++
 arch/x86_64/Makefile |   10 +++++++
 scripts/Makefile     |   11 ++++---
 scripts/mketrel.c    |   70 ++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 90 insertions(+), 5 deletions(-)
 create mode 100644 scripts/mketrel.c

diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index b00adb9..95949c3 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64
 	bool
 	default n
 
+config ELF_RELOCATABLE
+	bool
+	default y
+
 source "init/Kconfig"
 
 
diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile
index a81a84a..7c0434c 100644
--- a/arch/x86_64/Makefile
+++ b/arch/x86_64/Makefile
@@ -125,6 +125,16 @@ define archhelp
   echo  '  isoimage     - Create a boot CD-ROM image'
 endef
 
+ifeq ($(CONFIG_RELOCATABLE),y)
+define cmd_vmlinux__
+      $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
+      -T $(vmlinux-lds) $(vmlinux-init)		\
+      --start-group $(vmlinux-main) --end-group	\
+      $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \
+      && scripts/mketrel $@
+endef
+endif
+
 CLEAN_FILES += arch/$(ARCH)/boot/fdimage \
 	       arch/$(ARCH)/boot/image.iso \
 	       arch/$(ARCH)/boot/mtools.conf
diff --git a/scripts/Makefile b/scripts/Makefile
index 1c73c5a..ddba550 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -7,11 +7,12 @@
 # conmakehash:   Create chartable
 # conmakehash:	 Create arrays for initializing the kernel console tables
 
-hostprogs-$(CONFIG_KALLSYMS)     += kallsyms
-hostprogs-$(CONFIG_LOGO)         += pnmtologo
-hostprogs-$(CONFIG_VT)           += conmakehash
-hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash
-hostprogs-$(CONFIG_IKCONFIG)     += bin2c
+hostprogs-$(CONFIG_KALLSYMS)        += kallsyms
+hostprogs-$(CONFIG_LOGO)            += pnmtologo
+hostprogs-$(CONFIG_VT)              += conmakehash
+hostprogs-$(CONFIG_PROM_CONSOLE)    += conmakehash
+hostprogs-$(CONFIG_IKCONFIG)        += bin2c
+hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel
 
 always		:= $(hostprogs-y) $(hostprogs-m)
 
diff --git a/scripts/mketrel.c b/scripts/mketrel.c
new file mode 100644
index 0000000..aa0408a
--- /dev/null
+++ b/scripts/mketrel.c
@@ -0,0 +1,70 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <elf.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+#include <stdarg.h>
+#include <stdlib.h>
+
+static int fd;
+unsigned char e_ident[EI_NIDENT];
+
+void die(const char * str, ...)
+{
+	va_list args;
+	va_start(args, str);
+	vfprintf(stderr, str, args);
+	fputc('\n', stderr);
+	exit(1);
+}
+
+void file_open(const char *name)
+{
+	if ((fd = open(name, O_RDWR, 0)) < 0)
+		die("Unable to open `%s': %m", name);
+}
+
+static void mketrel(void)
+{
+	unsigned char e_type[2];
+	if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident))
+		die("Cannot read ELF header: %s\n", strerror(errno));
+
+	if (memcmp(e_ident, ELFMAG, 4) != 0)
+		die("No ELF magic\n");
+
+	if ((e_ident[EI_CLASS] != ELFCLASS64) &&
+	    (e_ident[EI_CLASS] != ELFCLASS32))
+		die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]);
+	
+	if ((e_ident[EI_DATA] != ELFDATA2LSB) &&
+	    (e_ident[EI_DATA] != ELFDATA2MSB))
+		die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]);
+
+	if (e_ident[EI_VERSION] != EV_CURRENT)
+		die("Unknown ELF version: %d\n", e_ident[EI_VERSION]);
+
+	if (e_ident[EI_DATA] == ELFDATA2LSB) {
+		e_type[0] = ET_DYN & 0xff;
+		e_type[1] = ET_DYN >> 8;
+	} else {
+		e_type[1] = ET_DYN & 0xff;
+		e_type[0] = ET_DYN >> 8;
+	}
+
+	if (write(fd, &e_type, sizeof(e_type)) != sizeof(e_type))
+		die("Cannot write ELF type: %s\n", strerror(errno));
+}
+
+int main(int argc, char **argv)
+{
+	if (argc != 2)
+		die("Usage: mketrel: vmlinux");
+	file_open(argv[1]);
+	mketrel();
+	close(fd);
+	return 0;
+}
-- 
1.5.1.1.181.g2de0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-04-30 15:12 ` Eric W. Biederman
@ 2007-04-30 15:17   ` Andi Kleen
  -1 siblings, 0 replies; 34+ messages in thread
From: Andi Kleen @ 2007-04-30 15:17 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andrew Morton, Jurriaan, Helge Hafting, linux-kernel, Horms,
	Kexec Mailing List

On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
> 
> Currently because vmlinux does not reflect that the kernel is relocatable
> we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
> c program to do what we cannot do with a linker script set the elf header
> type to ET_DYN.
> 
> Since last time I have fixed the type to be in my code ET_DYN (oops),
> and verified this works with kexec.  I realized while testing that we
> don't have anyway of identifying a kernel vmlinux as linux so we
> probably want to add an ELF note but that will be another patch.

The patch is ok for me, but does it pass Vivek's usual testing?

-Andi

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-04-30 15:17   ` Andi Kleen
  0 siblings, 0 replies; 34+ messages in thread
From: Andi Kleen @ 2007-04-30 15:17 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Kexec Mailing List, Jurriaan, linux-kernel, Helge Hafting, Horms,
	Andrew Morton

On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
> 
> Currently because vmlinux does not reflect that the kernel is relocatable
> we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
> c program to do what we cannot do with a linker script set the elf header
> type to ET_DYN.
> 
> Since last time I have fixed the type to be in my code ET_DYN (oops),
> and verified this works with kexec.  I realized while testing that we
> don't have anyway of identifying a kernel vmlinux as linux so we
> probably want to add an ELF note but that will be another patch.

The patch is ok for me, but does it pass Vivek's usual testing?

-Andi

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-04-30 15:17   ` Andi Kleen
@ 2007-05-01  3:55     ` Vivek Goyal
  -1 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-05-01  3:55 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Eric W. Biederman, Kexec Mailing List, Jurriaan, linux-kernel,
	Helge Hafting, Horms, Andrew Morton

On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote:
> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
> > 
> > Currently because vmlinux does not reflect that the kernel is relocatable
> > we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
> > c program to do what we cannot do with a linker script set the elf header
> > type to ET_DYN.
> > 
> > Since last time I have fixed the type to be in my code ET_DYN (oops),
> > and verified this works with kexec.  I realized while testing that we
> > don't have anyway of identifying a kernel vmlinux as linux so we
> > probably want to add an ELF note but that will be another patch.
> 
> The patch is ok for me, but does it pass Vivek's usual testing?

I am facing one issue with this patch. gdb can not analyze the
resulting kernel core file. Looks like gdb treats vmlinux differently if
ELF header type is "ET_DYN". It reads the symbol values incorrectly.

For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but
gdb somehow things that it is 0xffffffff008aaebf. Looks like it is
performing some relocation.

I am using GNU gdb Red Hat Linux (6.5-5.fc6rh).

Thanks
Vivek

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-01  3:55     ` Vivek Goyal
  0 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-05-01  3:55 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting, Horms,
	Eric W. Biederman, Andrew Morton

On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote:
> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
> > 
> > Currently because vmlinux does not reflect that the kernel is relocatable
> > we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
> > c program to do what we cannot do with a linker script set the elf header
> > type to ET_DYN.
> > 
> > Since last time I have fixed the type to be in my code ET_DYN (oops),
> > and verified this works with kexec.  I realized while testing that we
> > don't have anyway of identifying a kernel vmlinux as linux so we
> > probably want to add an ELF note but that will be another patch.
> 
> The patch is ok for me, but does it pass Vivek's usual testing?

I am facing one issue with this patch. gdb can not analyze the
resulting kernel core file. Looks like gdb treats vmlinux differently if
ELF header type is "ET_DYN". It reads the symbol values incorrectly.

For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but
gdb somehow things that it is 0xffffffff008aaebf. Looks like it is
performing some relocation.

I am using GNU gdb Red Hat Linux (6.5-5.fc6rh).

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-01  3:55     ` Vivek Goyal
@ 2007-05-01  4:20       ` Eric W. Biederman
  -1 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-05-01  4:20 UTC (permalink / raw)
  To: vgoyal
  Cc: Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan,
	Helge Hafting, Horms, Andrew Morton

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote:
>> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
>> > 
>> > Currently because vmlinux does not reflect that the kernel is relocatable
>> > we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
>> > c program to do what we cannot do with a linker script set the elf header
>> > type to ET_DYN.
>> > 
>> > Since last time I have fixed the type to be in my code ET_DYN (oops),
>> > and verified this works with kexec.  I realized while testing that we
>> > don't have anyway of identifying a kernel vmlinux as linux so we
>> > probably want to add an ELF note but that will be another patch.
>> 
>> The patch is ok for me, but does it pass Vivek's usual testing?
>
> I am facing one issue with this patch. gdb can not analyze the
> resulting kernel core file. Looks like gdb treats vmlinux differently if
> ELF header type is "ET_DYN". It reads the symbol values incorrectly.

Weird.

> For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but
> gdb somehow things that it is 0xffffffff008aaebf. Looks like it is
> performing some relocation.
>
> I am using GNU gdb Red Hat Linux (6.5-5.fc6rh).

Does it take a kernel core file to reproduce this problem?
Or can you just open up gdb on a vmlinux and look at the symbol
address?

At least without a core file it is working on with gdb 6.4.

Eric

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-01  4:20       ` Eric W. Biederman
  0 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-05-01  4:20 UTC (permalink / raw)
  To: vgoyal
  Cc: linux-kernel, Kexec Mailing List, Andi Kleen, Jurriaan,
	Helge Hafting, Horms, Andrew Morton

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote:
>> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
>> > 
>> > Currently because vmlinux does not reflect that the kernel is relocatable
>> > we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
>> > c program to do what we cannot do with a linker script set the elf header
>> > type to ET_DYN.
>> > 
>> > Since last time I have fixed the type to be in my code ET_DYN (oops),
>> > and verified this works with kexec.  I realized while testing that we
>> > don't have anyway of identifying a kernel vmlinux as linux so we
>> > probably want to add an ELF note but that will be another patch.
>> 
>> The patch is ok for me, but does it pass Vivek's usual testing?
>
> I am facing one issue with this patch. gdb can not analyze the
> resulting kernel core file. Looks like gdb treats vmlinux differently if
> ELF header type is "ET_DYN". It reads the symbol values incorrectly.

Weird.

> For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but
> gdb somehow things that it is 0xffffffff008aaebf. Looks like it is
> performing some relocation.
>
> I am using GNU gdb Red Hat Linux (6.5-5.fc6rh).

Does it take a kernel core file to reproduce this problem?
Or can you just open up gdb on a vmlinux and look at the symbol
address?

At least without a core file it is working on with gdb 6.4.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-01  4:20       ` Eric W. Biederman
@ 2007-05-01  5:06         ` Vivek Goyal
  -1 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-05-01  5:06 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan,
	Helge Hafting, Horms, Andrew Morton, vgoyal

On Mon, Apr 30, 2007 at 10:20:53PM -0600, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@in.ibm.com> writes:
> 
> > On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote:
> >> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
> >> > 
> >> > Currently because vmlinux does not reflect that the kernel is relocatable
> >> > we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
> >> > c program to do what we cannot do with a linker script set the elf header
> >> > type to ET_DYN.
> >> > 
> >> > Since last time I have fixed the type to be in my code ET_DYN (oops),
> >> > and verified this works with kexec.  I realized while testing that we
> >> > don't have anyway of identifying a kernel vmlinux as linux so we
> >> > probably want to add an ELF note but that will be another patch.
> >> 
> >> The patch is ok for me, but does it pass Vivek's usual testing?
> >
> > I am facing one issue with this patch. gdb can not analyze the
> > resulting kernel core file. Looks like gdb treats vmlinux differently if
> > ELF header type is "ET_DYN". It reads the symbol values incorrectly.
> 
> Weird.
> 
> > For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but
> > gdb somehow things that it is 0xffffffff008aaebf. Looks like it is
> > performing some relocation.
> >
> > I am using GNU gdb Red Hat Linux (6.5-5.fc6rh).
> 
> Does it take a kernel core file to reproduce this problem?
> Or can you just open up gdb on a vmlinux and look at the symbol
> address?

It takes a core file to reproduce the problem. Without core file gdb can
get right symbol addresses.

> 
> At least without a core file it is working on with gdb 6.4.
>

This seems to be a problem with gdb 6.5. I transferred the dump to a
different machine having GNU gdb 6.4, and it works fine there.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-01  5:06         ` Vivek Goyal
  0 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-05-01  5:06 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: linux-kernel, vgoyal, Kexec Mailing List, Andi Kleen, Jurriaan,
	Helge Hafting, Horms, Andrew Morton

On Mon, Apr 30, 2007 at 10:20:53PM -0600, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@in.ibm.com> writes:
> 
> > On Mon, Apr 30, 2007 at 05:17:07PM +0200, Andi Kleen wrote:
> >> On Monday 30 April 2007 17:12:39 Eric W. Biederman wrote:
> >> > 
> >> > Currently because vmlinux does not reflect that the kernel is relocatable
> >> > we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
> >> > c program to do what we cannot do with a linker script set the elf header
> >> > type to ET_DYN.
> >> > 
> >> > Since last time I have fixed the type to be in my code ET_DYN (oops),
> >> > and verified this works with kexec.  I realized while testing that we
> >> > don't have anyway of identifying a kernel vmlinux as linux so we
> >> > probably want to add an ELF note but that will be another patch.
> >> 
> >> The patch is ok for me, but does it pass Vivek's usual testing?
> >
> > I am facing one issue with this patch. gdb can not analyze the
> > resulting kernel core file. Looks like gdb treats vmlinux differently if
> > ELF header type is "ET_DYN". It reads the symbol values incorrectly.
> 
> Weird.
> 
> > For example, symbol value of "panic_timeout" is 0xffffffff808a1fa8 but
> > gdb somehow things that it is 0xffffffff008aaebf. Looks like it is
> > performing some relocation.
> >
> > I am using GNU gdb Red Hat Linux (6.5-5.fc6rh).
> 
> Does it take a kernel core file to reproduce this problem?
> Or can you just open up gdb on a vmlinux and look at the symbol
> address?

It takes a core file to reproduce the problem. Without core file gdb can
get right symbol addresses.

> 
> At least without a core file it is working on with gdb 6.4.
>

This seems to be a problem with gdb 6.5. I transferred the dump to a
different machine having GNU gdb 6.4, and it works fine there.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-01  5:06         ` Vivek Goyal
@ 2007-05-01  5:26           ` Eric W. Biederman
  -1 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-05-01  5:26 UTC (permalink / raw)
  To: vgoyal
  Cc: Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan,
	Helge Hafting, Horms, Andrew Morton

Vivek Goyal <vgoyal@in.ibm.com> writes:


>> At least without a core file it is working on with gdb 6.4.
>>
>
> This seems to be a problem with gdb 6.5. I transferred the dump to a
> different machine having GNU gdb 6.4, and it works fine there.

Ok.  The difference between those two symbols didn't seem to make
any sense, so a gdb bug makes sense.

Cool.  Then the patch is good. :)

Eric

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-01  5:26           ` Eric W. Biederman
  0 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-05-01  5:26 UTC (permalink / raw)
  To: vgoyal
  Cc: linux-kernel, Kexec Mailing List, Andi Kleen, Jurriaan,
	Helge Hafting, Horms, Andrew Morton

Vivek Goyal <vgoyal@in.ibm.com> writes:


>> At least without a core file it is working on with gdb 6.4.
>>
>
> This seems to be a problem with gdb 6.5. I transferred the dump to a
> different machine having GNU gdb 6.4, and it works fine there.

Ok.  The difference between those two symbols didn't seem to make
any sense, so a gdb bug makes sense.

Cool.  Then the patch is good. :)

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-01  6:25             ` Andi Kleen
@ 2007-05-01  5:54               ` Eric W. Biederman
  -1 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-05-01  5:54 UTC (permalink / raw)
  To: Andi Kleen
  Cc: vgoyal, Kexec Mailing List, linux-kernel, Jurriaan,
	Helge Hafting, Horms, Andrew Morton

Andi Kleen <ak@suse.de> writes:

> On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@in.ibm.com> writes:
>> 
>> 
>> >> At least without a core file it is working on with gdb 6.4.
>> >>
>> >
>> > This seems to be a problem with gdb 6.5. I transferred the dump to a
>> > different machine having GNU gdb 6.4, and it works fine there.
>> 
>> Ok.  The difference between those two symbols didn't seem to make
>> any sense, so a gdb bug makes sense.
>> 
>> Cool.  Then the patch is good. :)
>
> It would still make any gdb 6.5 users unhappy. If no workaround can be found
> I guess we'll need a CONFIG of some sort?

It is probably worth reproducing this bug with a PIE executable.
But it looks very much like gdb got it wrong, or else there is some
slight mismatch between our core dump and gdb.

Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction
with a core dump I would not say the problem is in vmlinux.

Rather there seems to be something messed up when gdb 6.5 tries to match
up the kernel core dump with the kernel.  The offset for the symbol
Vivek gave was 0x7fff70e9. ???  Although that is almost 2M...

Vivek could we see the program headers of your core file?

>From what I can tell what is left to figure out is do we have
a bug in gdb 6.5 or do we have a bug in our core file generation.

Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it
wrong.  I'm probably just burnt out with binutils problems whenever
I try and do something interesting.  But I'm just not inclined that
the bleeding edge tools are working properly while there kernel
core dump mechanism would mess up with a two byte field change.

It does make sense to root cause this if we can.  If it's a gdb
problem it should also apply to PIE executables, and should irritate
a few users.

Regardless last I heard it was crash that was the primary analysis
tool and not gdb anyway.  With gdb serving as the double check to make
certain that the kernel core dump was in a reasonably standard format.

Eric

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-01  5:54               ` Eric W. Biederman
  0 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-05-01  5:54 UTC (permalink / raw)
  To: Andi Kleen
  Cc: Horms, Kexec Mailing List, linux-kernel, Jurriaan, Helge Hafting,
	vgoyal, Andrew Morton

Andi Kleen <ak@suse.de> writes:

> On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote:
>> Vivek Goyal <vgoyal@in.ibm.com> writes:
>> 
>> 
>> >> At least without a core file it is working on with gdb 6.4.
>> >>
>> >
>> > This seems to be a problem with gdb 6.5. I transferred the dump to a
>> > different machine having GNU gdb 6.4, and it works fine there.
>> 
>> Ok.  The difference between those two symbols didn't seem to make
>> any sense, so a gdb bug makes sense.
>> 
>> Cool.  Then the patch is good. :)
>
> It would still make any gdb 6.5 users unhappy. If no workaround can be found
> I guess we'll need a CONFIG of some sort?

It is probably worth reproducing this bug with a PIE executable.
But it looks very much like gdb got it wrong, or else there is some
slight mismatch between our core dump and gdb.

Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction
with a core dump I would not say the problem is in vmlinux.

Rather there seems to be something messed up when gdb 6.5 tries to match
up the kernel core dump with the kernel.  The offset for the symbol
Vivek gave was 0x7fff70e9. ???  Although that is almost 2M...

Vivek could we see the program headers of your core file?

From what I can tell what is left to figure out is do we have
a bug in gdb 6.5 or do we have a bug in our core file generation.

Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it
wrong.  I'm probably just burnt out with binutils problems whenever
I try and do something interesting.  But I'm just not inclined that
the bleeding edge tools are working properly while there kernel
core dump mechanism would mess up with a two byte field change.

It does make sense to root cause this if we can.  If it's a gdb
problem it should also apply to PIE executables, and should irritate
a few users.

Regardless last I heard it was crash that was the primary analysis
tool and not gdb anyway.  With gdb serving as the double check to make
certain that the kernel core dump was in a reasonably standard format.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-01  5:26           ` Eric W. Biederman
@ 2007-05-01  6:25             ` Andi Kleen
  -1 siblings, 0 replies; 34+ messages in thread
From: Andi Kleen @ 2007-05-01  6:25 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: vgoyal, Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan,
	Helge Hafting, Horms, Andrew Morton

On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@in.ibm.com> writes:
> 
> 
> >> At least without a core file it is working on with gdb 6.4.
> >>
> >
> > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > different machine having GNU gdb 6.4, and it works fine there.
> 
> Ok.  The difference between those two symbols didn't seem to make
> any sense, so a gdb bug makes sense.
> 
> Cool.  Then the patch is good. :)

It would still make any gdb 6.5 users unhappy. If no workaround can be found
I guess we'll need a CONFIG of some sort?

-Andi

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-01  6:25             ` Andi Kleen
  0 siblings, 0 replies; 34+ messages in thread
From: Andi Kleen @ 2007-05-01  6:25 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Horms, linux-kernel, Kexec Mailing List, Andi Kleen, Jurriaan,
	Helge Hafting, vgoyal, Andrew Morton

On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@in.ibm.com> writes:
> 
> 
> >> At least without a core file it is working on with gdb 6.4.
> >>
> >
> > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > different machine having GNU gdb 6.4, and it works fine there.
> 
> Ok.  The difference between those two symbols didn't seem to make
> any sense, so a gdb bug makes sense.
> 
> Cool.  Then the patch is good. :)

It would still make any gdb 6.5 users unhappy. If no workaround can be found
I guess we'll need a CONFIG of some sort?

-Andi

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-01  5:54               ` Eric W. Biederman
@ 2007-05-01  6:44                 ` Vivek Goyal
  -1 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-05-01  6:44 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andi Kleen, Kexec Mailing List, linux-kernel, Jurriaan,
	Helge Hafting, Horms, Andrew Morton

On Mon, Apr 30, 2007 at 11:54:22PM -0600, Eric W. Biederman wrote:
> Andi Kleen <ak@suse.de> writes:
> 
> > On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote:
> >> Vivek Goyal <vgoyal@in.ibm.com> writes:
> >> 
> >> 
> >> >> At least without a core file it is working on with gdb 6.4.
> >> >>
> >> >
> >> > This seems to be a problem with gdb 6.5. I transferred the dump to a
> >> > different machine having GNU gdb 6.4, and it works fine there.
> >> 
> >> Ok.  The difference between those two symbols didn't seem to make
> >> any sense, so a gdb bug makes sense.
> >> 
> >> Cool.  Then the patch is good. :)
> >
> > It would still make any gdb 6.5 users unhappy. If no workaround can be found
> > I guess we'll need a CONFIG of some sort?
> 
> It is probably worth reproducing this bug with a PIE executable.
> But it looks very much like gdb got it wrong, or else there is some
> slight mismatch between our core dump and gdb.
> 
> Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction
> with a core dump I would not say the problem is in vmlinux.
> 
> Rather there seems to be something messed up when gdb 6.5 tries to match
> up the kernel core dump with the kernel.  The offset for the symbol
> Vivek gave was 0x7fff70e9. ???  Although that is almost 2M...
> 
> Vivek could we see the program headers of your core file?
> 

Hi Eric,

Following are program headers of my core file. They look sane.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x0000000000000190 0x0000000000000000 0x0000000000000000
                 0x0000000000000b20 0x0000000000000b20         0
  LOAD           0x0000000000000cb0 0xffffffff80200000 0x0000000000200000
                 0x0000000000742000 0x0000000000742000  RWE    0
  LOAD           0x0000000000742cb0 0xffff810000000000 0x0000000000000000
                 0x00000000000a0000 0x00000000000a0000  RWE    0
  LOAD           0x00000000007e2cb0 0xffff810000100000 0x0000000000100000
                 0x0000000000f00000 0x0000000000f00000  RWE    0
  LOAD           0x00000000016e2cb0 0xffff810009000000 0x0000000009000000
                 0x00000000c6f8dc80 0x00000000c6f8dc80  RWE    0
  LOAD           0x00000000c8670930 0xffff810100000000 0x0000000100000000
                 0x0000000130000000 0x0000000130000000  RWE    0

First PT_LOAD header is mapping kernel text/data and others just mapping
physical memory in kernel linear virtual address range.

> >From what I can tell what is left to figure out is do we have
> a bug in gdb 6.5 or do we have a bug in our core file generation.
> 

Given the fact it works well with gdb 6.4 as well as 6.1 (crash uses gdb 6.1
as backend and crash is working fine). I would think that it is gdb bug.

> Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it
> wrong.  I'm probably just burnt out with binutils problems whenever
> I try and do something interesting.  But I'm just not inclined that
> the bleeding edge tools are working properly while there kernel
> core dump mechanism would mess up with a two byte field change.
> 
> It does make sense to root cause this if we can.  If it's a gdb
> problem it should also apply to PIE executables, and should irritate
> a few users.
> 
> Regardless last I heard it was crash that was the primary analysis
> tool and not gdb anyway.  With gdb serving as the double check to make
> certain that the kernel core dump was in a reasonably standard format.

I would consider gdb to be equally important, especially because many
a times crash is broken with latest version of kernels (as some data
structures or some mechanism has changed) and gdb is the only one who
can open the dump.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-01  6:44                 ` Vivek Goyal
  0 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-05-01  6:44 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: linux-kernel, Kexec Mailing List, Andi Kleen, Jurriaan,
	Helge Hafting, Horms, Andrew Morton

On Mon, Apr 30, 2007 at 11:54:22PM -0600, Eric W. Biederman wrote:
> Andi Kleen <ak@suse.de> writes:
> 
> > On Mon, Apr 30, 2007 at 11:26:50PM -0600, Eric W. Biederman wrote:
> >> Vivek Goyal <vgoyal@in.ibm.com> writes:
> >> 
> >> 
> >> >> At least without a core file it is working on with gdb 6.4.
> >> >>
> >> >
> >> > This seems to be a problem with gdb 6.5. I transferred the dump to a
> >> > different machine having GNU gdb 6.4, and it works fine there.
> >> 
> >> Ok.  The difference between those two symbols didn't seem to make
> >> any sense, so a gdb bug makes sense.
> >> 
> >> Cool.  Then the patch is good. :)
> >
> > It would still make any gdb 6.5 users unhappy. If no workaround can be found
> > I guess we'll need a CONFIG of some sort?
> 
> It is probably worth reproducing this bug with a PIE executable.
> But it looks very much like gdb got it wrong, or else there is some
> slight mismatch between our core dump and gdb.
> 
> Given that gdb 6.5 handles the vmlinux fine when it isn't in conjunction
> with a core dump I would not say the problem is in vmlinux.
> 
> Rather there seems to be something messed up when gdb 6.5 tries to match
> up the kernel core dump with the kernel.  The offset for the symbol
> Vivek gave was 0x7fff70e9. ???  Although that is almost 2M...
> 
> Vivek could we see the program headers of your core file?
> 

Hi Eric,

Following are program headers of my core file. They look sane.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  NOTE           0x0000000000000190 0x0000000000000000 0x0000000000000000
                 0x0000000000000b20 0x0000000000000b20         0
  LOAD           0x0000000000000cb0 0xffffffff80200000 0x0000000000200000
                 0x0000000000742000 0x0000000000742000  RWE    0
  LOAD           0x0000000000742cb0 0xffff810000000000 0x0000000000000000
                 0x00000000000a0000 0x00000000000a0000  RWE    0
  LOAD           0x00000000007e2cb0 0xffff810000100000 0x0000000000100000
                 0x0000000000f00000 0x0000000000f00000  RWE    0
  LOAD           0x00000000016e2cb0 0xffff810009000000 0x0000000009000000
                 0x00000000c6f8dc80 0x00000000c6f8dc80  RWE    0
  LOAD           0x00000000c8670930 0xffff810100000000 0x0000000100000000
                 0x0000000130000000 0x0000000130000000  RWE    0

First PT_LOAD header is mapping kernel text/data and others just mapping
physical memory in kernel linear virtual address range.

> >From what I can tell what is left to figure out is do we have
> a bug in gdb 6.5 or do we have a bug in our core file generation.
> 

Given the fact it works well with gdb 6.4 as well as 6.1 (crash uses gdb 6.1
as backend and crash is working fine). I would think that it is gdb bug.

> Right now I'm inclined to believe that the fedora core 6? gdb 6.5 got it
> wrong.  I'm probably just burnt out with binutils problems whenever
> I try and do something interesting.  But I'm just not inclined that
> the bleeding edge tools are working properly while there kernel
> core dump mechanism would mess up with a two byte field change.
> 
> It does make sense to root cause this if we can.  If it's a gdb
> problem it should also apply to PIE executables, and should irritate
> a few users.
> 
> Regardless last I heard it was crash that was the primary analysis
> tool and not gdb anyway.  With gdb serving as the double check to make
> certain that the kernel core dump was in a reasonably standard format.

I would consider gdb to be equally important, especially because many
a times crash is broken with latest version of kernels (as some data
structures or some mechanism has changed) and gdb is the only one who
can open the dump.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-01  5:06         ` Vivek Goyal
@ 2007-05-28 10:54           ` Bernhard Walle
  -1 siblings, 0 replies; 34+ messages in thread
From: Bernhard Walle @ 2007-05-28 10:54 UTC (permalink / raw)
  To: Andi Kleen, vgoyal; +Cc: kexec, linux-kernel

* Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> This seems to be a problem with gdb 6.5. I transferred the dump to a
> different machine having GNU gdb 6.4, and it works fine there.

What's the state of it? Andy, was the GDB breakage the reason why you
didn't merge it? Did someone file a GDB bug?



Thanks,
   Bernhard

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-28 10:54           ` Bernhard Walle
  0 siblings, 0 replies; 34+ messages in thread
From: Bernhard Walle @ 2007-05-28 10:54 UTC (permalink / raw)
  To: Andi Kleen, vgoyal; +Cc: kexec, linux-kernel

* Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> This seems to be a problem with gdb 6.5. I transferred the dump to a
> different machine having GNU gdb 6.4, and it works fine there.

What's the state of it? Andy, was the GDB breakage the reason why you
didn't merge it? Did someone file a GDB bug?



Thanks,
   Bernhard

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-28 10:54           ` Bernhard Walle
@ 2007-05-28 11:09             ` Vivek Goyal
  -1 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-05-28 11:09 UTC (permalink / raw)
  To: Andi Kleen, kexec, linux-kernel, Bernhard Walle

On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > different machine having GNU gdb 6.4, and it works fine there.
> 
> What's the state of it? Andy, was the GDB breakage the reason why you
> didn't merge it? Did someone file a GDB bug?
> 

I had sent a mail to gdb mailing list but no response. Did not raise
a bug though.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-28 11:09             ` Vivek Goyal
  0 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-05-28 11:09 UTC (permalink / raw)
  To: Andi Kleen, kexec, linux-kernel, Bernhard Walle

On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > different machine having GNU gdb 6.4, and it works fine there.
> 
> What's the state of it? Andy, was the GDB breakage the reason why you
> didn't merge it? Did someone file a GDB bug?
> 

I had sent a mail to gdb mailing list but no response. Did not raise
a bug though.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-28 11:09             ` Vivek Goyal
@ 2007-05-28 14:39               ` Bernhard Walle
  -1 siblings, 0 replies; 34+ messages in thread
From: Bernhard Walle @ 2007-05-28 14:39 UTC (permalink / raw)
  To: Vivek Goyal; +Cc: Andi Kleen, kexec, linux-kernel

* Vivek Goyal <vgoyal@in.ibm.com> [2007-05-28 13:09]:
> On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote:
> > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> > > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > > different machine having GNU gdb 6.4, and it works fine there.
> > 
> > What's the state of it? Andy, was the GDB breakage the reason why you
> > didn't merge it? Did someone file a GDB bug?
> 
> I had sent a mail to gdb mailing list but no response. Did not raise
> a bug though.

BTW: Did anyone test with GDB 6.6?


Thanks,
   Bernhard

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-28 14:39               ` Bernhard Walle
  0 siblings, 0 replies; 34+ messages in thread
From: Bernhard Walle @ 2007-05-28 14:39 UTC (permalink / raw)
  To: Vivek Goyal; +Cc: kexec, Andi Kleen, linux-kernel

* Vivek Goyal <vgoyal@in.ibm.com> [2007-05-28 13:09]:
> On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote:
> > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> > > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > > different machine having GNU gdb 6.4, and it works fine there.
> > 
> > What's the state of it? Andy, was the GDB breakage the reason why you
> > didn't merge it? Did someone file a GDB bug?
> 
> I had sent a mail to gdb mailing list but no response. Did not raise
> a bug though.

BTW: Did anyone test with GDB 6.6?


Thanks,
   Bernhard

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-28 10:54           ` Bernhard Walle
@ 2007-05-28 14:57             ` Andi Kleen
  -1 siblings, 0 replies; 34+ messages in thread
From: Andi Kleen @ 2007-05-28 14:57 UTC (permalink / raw)
  To: Bernhard Walle; +Cc: vgoyal, kexec, linux-kernel

On Monday 28 May 2007 12:54:42 Bernhard Walle wrote:
> * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > different machine having GNU gdb 6.4, and it works fine there.
> 
> What's the state of it? Andy, was the GDB breakage the reason why you
> didn't merge it? 

Yes, I was waiting for Vivek to figure that out.

-Andi

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-05-28 14:57             ` Andi Kleen
  0 siblings, 0 replies; 34+ messages in thread
From: Andi Kleen @ 2007-05-28 14:57 UTC (permalink / raw)
  To: Bernhard Walle; +Cc: vgoyal, kexec, linux-kernel

On Monday 28 May 2007 12:54:42 Bernhard Walle wrote:
> * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > different machine having GNU gdb 6.4, and it works fine there.
> 
> What's the state of it? Andy, was the GDB breakage the reason why you
> didn't merge it? 

Yes, I was waiting for Vivek to figure that out.

-Andi

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-05-28 14:39               ` Bernhard Walle
@ 2007-06-01 12:26                 ` Bernhard Walle
  -1 siblings, 0 replies; 34+ messages in thread
From: Bernhard Walle @ 2007-06-01 12:26 UTC (permalink / raw)
  To: Vivek Goyal, Andi Kleen, kexec, linux-kernel

* Bernhard Walle <bwalle@suse.de> [2007-05-28 16:39]:
> * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-28 13:09]:
> > On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote:
> > > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> > > > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > > > different machine having GNU gdb 6.4, and it works fine there.
> > > 
> > > What's the state of it? Andy, was the GDB breakage the reason why you
> > > didn't merge it? Did someone file a GDB bug?
> > 
> > I had sent a mail to gdb mailing list but no response. Did not raise
> > a bug though.
> 
> BTW: Did anyone test with GDB 6.6?

/me. But I get the same error as with GDB 6.5. I'm looking if I can
find the cause of the problem.


Thanks,
   Bernhard

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-06-01 12:26                 ` Bernhard Walle
  0 siblings, 0 replies; 34+ messages in thread
From: Bernhard Walle @ 2007-06-01 12:26 UTC (permalink / raw)
  To: Vivek Goyal, Andi Kleen, kexec, linux-kernel

* Bernhard Walle <bwalle@suse.de> [2007-05-28 16:39]:
> * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-28 13:09]:
> > On Mon, May 28, 2007 at 12:54:42PM +0200, Bernhard Walle wrote:
> > > * Vivek Goyal <vgoyal@in.ibm.com> [2007-05-01 07:06]:
> > > > This seems to be a problem with gdb 6.5. I transferred the dump to a
> > > > different machine having GNU gdb 6.4, and it works fine there.
> > > 
> > > What's the state of it? Andy, was the GDB breakage the reason why you
> > > didn't merge it? Did someone file a GDB bug?
> > 
> > I had sent a mail to gdb mailing list but no response. Did not raise
> > a bug though.
> 
> BTW: Did anyone test with GDB 6.6?

/me. But I get the same error as with GDB 6.5. I'm looking if I can
find the cause of the problem.


Thanks,
   Bernhard

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-04-24  6:31                         ` Vivek Goyal
@ 2007-04-24  7:21                           ` Eric W. Biederman
  -1 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-04-24  7:21 UTC (permalink / raw)
  To: vgoyal
  Cc: Andrew Morton, Andi Kleen, Jurriaan, Helge Hafting, linux-kernel,
	Horms, Kexec Mailing List

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote:
>> 
>> Currently because vmlinux does not reflect that the kernel is relocatable
>> we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
>> c program to do what we cannot do with a linker script, set the elf header
>> type to ET_DYN.
>> 
>> This should remove the last obstacle to removing CONFIG_PHYSICAL_START
>> on x86_64.
>> 
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>
> [Dropping fastboot mailing list from CC as kexec mailing list is new list
>  for this discussion]
>
> [..]
>> +void file_open(const char *name)
>> +{
>> +	if ((fd = open(name, O_RDWR, 0)) < 0)
>> +		die("Unable to open `%s': %m", name);
>> +}
>> +
>> +static void mketrel(void)
>> +{
>> +	unsigned char e_type[2];
>> +	if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident))
>> +		die("Cannot read ELF header: %s\n", strerror(errno));
>> +
>> +	if (memcmp(e_ident, ELFMAG, 4) != 0)
>> +		die("No ELF magic\n");
>> +
>> +	if ((e_ident[EI_CLASS] != ELFCLASS64) &&
>> +	    (e_ident[EI_CLASS] != ELFCLASS32))
>> +		die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]);
>> +	
>> +	if ((e_ident[EI_DATA] != ELFDATA2LSB) &&
>> +	    (e_ident[EI_DATA] != ELFDATA2MSB))
>> +		die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]);
>> +
>> +	if (e_ident[EI_VERSION] != EV_CURRENT)
>> +		die("Unknown ELF version: %d\n", e_ident[EI_VERSION]);
>> +
>> +	if (e_ident[EI_DATA] == ELFDATA2LSB) {
>> +		e_type[0] = ET_REL & 0xff;
>> +		e_type[1] = ET_REL >> 8;
>> +	} else {
>> +		e_type[1] = ET_REL & 0xff;
>> +		e_type[0] = ET_REL >> 8;
>> +	}
>
> Hi Eric,
>
> Should this be ET_REL or ET_DYN? kexec refuses to load this vmlinux
> as it does not find it to be executable type.

Doh.  It should be ET_DYN.  I had relocatable much to much on the brain,
and so I stuffed in the wrong type.

> I am not well versed with various conventions but if I go through "Executable
> and Linking Format" document, this is what it says about various file types.
>
> • A relocatable file holds code and data suitable for linking with other
>   object files to create an executable or a shared object file.
>
> • An executable file holds a program suitable for execution.
>
> • A shared object file holds code and data suitable for linking in two
>   contexts. First, the link editor may process it with other relocatable and
>   shared object files to create another object file. Second, the dynamic
>   linker combines it with an executable file and other shared objects
>   to create a process image.
>
> So above does not seem to fit in the ET_REL type. We can't relink this
> vmlinux? And it does not seem to fit in ET_DYN definition too. We are
> not relinking this vmlinux with another executable or other relocatable
> files.
>
> I remember once you mentioned the term dynamic executable which can be
> loaded at a non-compiled address and let run without requiring any
> relocation processing. This vmlinux will fall in that category but can't 
> relate it to standard elf file definitions.

Sorry about that.  

ET_DYN without a PT_DYNAMIC segment, without a PT_INTERP segment,
and with a valid entry point is exactly that.  Loaders never perform
relocation processing on a ET_DYN executable but they are allowed to
shift all of the addresses by a single delta so long as all of the
alignment restrictions are honored.

Relocation processing when it happens comes from the dynamic linker,
which is set in PT_INTERP and the dynamic linker looks a PT_DYNAMIC
to figure out what relocations are available for processing.

The basic issue is that ld don't really comprehend what we are doing
since we are building a position independent executable in a way
that the normal tools don't allow, so we have to poke the header.

If we had compiled with -fPIC we could have specified -pie or
--pic-executable to ld and it would have done the right thing.
But as it is our executable only changes physical addresses and
not virtual addresses something completely foreign to ld.

Eric

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-04-24  7:21                           ` Eric W. Biederman
  0 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-04-24  7:21 UTC (permalink / raw)
  To: vgoyal
  Cc: Kexec Mailing List, Jurriaan, linux-kernel, Andi Kleen,
	Helge Hafting, Horms, Andrew Morton

[-- Attachment #1: Type: text/plain, Size: 4202 bytes --]

Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote:
>> 
>> Currently because vmlinux does not reflect that the kernel is relocatable
>> we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
>> c program to do what we cannot do with a linker script, set the elf header
>> type to ET_DYN.
>> 
>> This should remove the last obstacle to removing CONFIG_PHYSICAL_START
>> on x86_64.
>> 
>> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>
> [Dropping fastboot mailing list from CC as kexec mailing list is new list
>  for this discussion]
>
> [..]
>> +void file_open(const char *name)
>> +{
>> +	if ((fd = open(name, O_RDWR, 0)) < 0)
>> +		die("Unable to open `%s': %m", name);
>> +}
>> +
>> +static void mketrel(void)
>> +{
>> +	unsigned char e_type[2];
>> +	if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident))
>> +		die("Cannot read ELF header: %s\n", strerror(errno));
>> +
>> +	if (memcmp(e_ident, ELFMAG, 4) != 0)
>> +		die("No ELF magic\n");
>> +
>> +	if ((e_ident[EI_CLASS] != ELFCLASS64) &&
>> +	    (e_ident[EI_CLASS] != ELFCLASS32))
>> +		die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]);
>> +	
>> +	if ((e_ident[EI_DATA] != ELFDATA2LSB) &&
>> +	    (e_ident[EI_DATA] != ELFDATA2MSB))
>> +		die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]);
>> +
>> +	if (e_ident[EI_VERSION] != EV_CURRENT)
>> +		die("Unknown ELF version: %d\n", e_ident[EI_VERSION]);
>> +
>> +	if (e_ident[EI_DATA] == ELFDATA2LSB) {
>> +		e_type[0] = ET_REL & 0xff;
>> +		e_type[1] = ET_REL >> 8;
>> +	} else {
>> +		e_type[1] = ET_REL & 0xff;
>> +		e_type[0] = ET_REL >> 8;
>> +	}
>
> Hi Eric,
>
> Should this be ET_REL or ET_DYN? kexec refuses to load this vmlinux
> as it does not find it to be executable type.

Doh.  It should be ET_DYN.  I had relocatable much to much on the brain,
and so I stuffed in the wrong type.

> I am not well versed with various conventions but if I go through "Executable
> and Linking Format" document, this is what it says about various file types.
>
> • A relocatable file holds code and data suitable for linking with other
>   object files to create an executable or a shared object file.
>
> • An executable file holds a program suitable for execution.
>
> • A shared object file holds code and data suitable for linking in two
>   contexts. First, the link editor may process it with other relocatable and
>   shared object files to create another object file. Second, the dynamic
>   linker combines it with an executable file and other shared objects
>   to create a process image.
>
> So above does not seem to fit in the ET_REL type. We can't relink this
> vmlinux? And it does not seem to fit in ET_DYN definition too. We are
> not relinking this vmlinux with another executable or other relocatable
> files.
>
> I remember once you mentioned the term dynamic executable which can be
> loaded at a non-compiled address and let run without requiring any
> relocation processing. This vmlinux will fall in that category but can't 
> relate it to standard elf file definitions.

Sorry about that.  

ET_DYN without a PT_DYNAMIC segment, without a PT_INTERP segment,
and with a valid entry point is exactly that.  Loaders never perform
relocation processing on a ET_DYN executable but they are allowed to
shift all of the addresses by a single delta so long as all of the
alignment restrictions are honored.

Relocation processing when it happens comes from the dynamic linker,
which is set in PT_INTERP and the dynamic linker looks a PT_DYNAMIC
to figure out what relocations are available for processing.

The basic issue is that ld don't really comprehend what we are doing
since we are building a position independent executable in a way
that the normal tools don't allow, so we have to poke the header.

If we had compiled with -fPIC we could have specified -pie or
--pic-executable to ld and it would have done the right thing.
But as it is our executable only changes physical addresses and
not virtual addresses something completely foreign to ld.

Eric


[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-04-23  5:12                       ` Eric W. Biederman
@ 2007-04-24  6:31                         ` Vivek Goyal
  -1 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-04-24  6:31 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Andrew Morton, Andi Kleen, Jurriaan, Helge Hafting, linux-kernel,
	Horms, Kexec Mailing List

On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote:
> 
> Currently because vmlinux does not reflect that the kernel is relocatable
> we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
> c program to do what we cannot do with a linker script, set the elf header
> type to ET_DYN.
> 
> This should remove the last obstacle to removing CONFIG_PHYSICAL_START
> on x86_64.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

[Dropping fastboot mailing list from CC as kexec mailing list is new list
 for this discussion]

[..]
> +void file_open(const char *name)
> +{
> +	if ((fd = open(name, O_RDWR, 0)) < 0)
> +		die("Unable to open `%s': %m", name);
> +}
> +
> +static void mketrel(void)
> +{
> +	unsigned char e_type[2];
> +	if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident))
> +		die("Cannot read ELF header: %s\n", strerror(errno));
> +
> +	if (memcmp(e_ident, ELFMAG, 4) != 0)
> +		die("No ELF magic\n");
> +
> +	if ((e_ident[EI_CLASS] != ELFCLASS64) &&
> +	    (e_ident[EI_CLASS] != ELFCLASS32))
> +		die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]);
> +	
> +	if ((e_ident[EI_DATA] != ELFDATA2LSB) &&
> +	    (e_ident[EI_DATA] != ELFDATA2MSB))
> +		die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]);
> +
> +	if (e_ident[EI_VERSION] != EV_CURRENT)
> +		die("Unknown ELF version: %d\n", e_ident[EI_VERSION]);
> +
> +	if (e_ident[EI_DATA] == ELFDATA2LSB) {
> +		e_type[0] = ET_REL & 0xff;
> +		e_type[1] = ET_REL >> 8;
> +	} else {
> +		e_type[1] = ET_REL & 0xff;
> +		e_type[0] = ET_REL >> 8;
> +	}

Hi Eric,

Should this be ET_REL or ET_DYN? kexec refuses to load this vmlinux
as it does not find it to be executable type.

I am not well versed with various conventions but if I go through "Executable
and Linking Format" document, this is what it says about various file types.

• A relocatable file holds code and data suitable for linking with other
  object files to create an executable or a shared object file.

• An executable file holds a program suitable for execution.

• A shared object file holds code and data suitable for linking in two
  contexts. First, the link editor may process it with other relocatable and
  shared object files to create another object file. Second, the dynamic
  linker combines it with an executable file and other shared objects
  to create a process image.

So above does not seem to fit in the ET_REL type. We can't relink this
vmlinux? And it does not seem to fit in ET_DYN definition too. We are
not relinking this vmlinux with another executable or other relocatable
files.

I remember once you mentioned the term dynamic executable which can be
loaded at a non-compiled address and let run without requiring any
relocation processing. This vmlinux will fall in that category but can't 
relate it to standard elf file definitions.

Thanks
Vivek

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-04-24  6:31                         ` Vivek Goyal
  0 siblings, 0 replies; 34+ messages in thread
From: Vivek Goyal @ 2007-04-24  6:31 UTC (permalink / raw)
  To: Eric W. Biederman
  Cc: Kexec Mailing List, Jurriaan, linux-kernel, Andi Kleen,
	Helge Hafting, Horms, Andrew Morton

On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote:
> 
> Currently because vmlinux does not reflect that the kernel is relocatable
> we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
> c program to do what we cannot do with a linker script, set the elf header
> type to ET_DYN.
> 
> This should remove the last obstacle to removing CONFIG_PHYSICAL_START
> on x86_64.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

[Dropping fastboot mailing list from CC as kexec mailing list is new list
 for this discussion]

[..]
> +void file_open(const char *name)
> +{
> +	if ((fd = open(name, O_RDWR, 0)) < 0)
> +		die("Unable to open `%s': %m", name);
> +}
> +
> +static void mketrel(void)
> +{
> +	unsigned char e_type[2];
> +	if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident))
> +		die("Cannot read ELF header: %s\n", strerror(errno));
> +
> +	if (memcmp(e_ident, ELFMAG, 4) != 0)
> +		die("No ELF magic\n");
> +
> +	if ((e_ident[EI_CLASS] != ELFCLASS64) &&
> +	    (e_ident[EI_CLASS] != ELFCLASS32))
> +		die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]);
> +	
> +	if ((e_ident[EI_DATA] != ELFDATA2LSB) &&
> +	    (e_ident[EI_DATA] != ELFDATA2MSB))
> +		die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]);
> +
> +	if (e_ident[EI_VERSION] != EV_CURRENT)
> +		die("Unknown ELF version: %d\n", e_ident[EI_VERSION]);
> +
> +	if (e_ident[EI_DATA] == ELFDATA2LSB) {
> +		e_type[0] = ET_REL & 0xff;
> +		e_type[1] = ET_REL >> 8;
> +	} else {
> +		e_type[1] = ET_REL & 0xff;
> +		e_type[0] = ET_REL >> 8;
> +	}

Hi Eric,

Should this be ET_REL or ET_DYN? kexec refuses to load this vmlinux
as it does not find it to be executable type.

I am not well versed with various conventions but if I go through "Executable
and Linking Format" document, this is what it says about various file types.

• A relocatable file holds code and data suitable for linking with other
  object files to create an executable or a shared object file.

• An executable file holds a program suitable for execution.

• A shared object file holds code and data suitable for linking in two
  contexts. First, the link editor may process it with other relocatable and
  shared object files to create another object file. Second, the dynamic
  linker combines it with an executable file and other shared objects
  to create a process image.

So above does not seem to fit in the ET_REL type. We can't relink this
vmlinux? And it does not seem to fit in ET_DYN definition too. We are
not relinking this vmlinux with another executable or other relocatable
files.

I remember once you mentioned the term dynamic executable which can be
loaded at a non-compiled address and let run without requiring any
relocation processing. This vmlinux will fall in that category but can't 
relate it to standard elf file definitions.

Thanks
Vivek

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 34+ messages in thread

* [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
  2007-04-03 10:03                   ` Vivek Goyal
@ 2007-04-23  5:12                       ` Eric W. Biederman
  0 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-04-23  5:12 UTC (permalink / raw)
  To: Andrew Morton, Andi Kleen
  Cc: vgoyal, Jurriaan, Helge Hafting, linux-kernel, Magnus Damm,
	Horms, thunder7, fastboot, Kexec Mailing List


Currently because vmlinux does not reflect that the kernel is relocatable
we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
c program to do what we cannot do with a linker script, set the elf header
type to ET_DYN.

This should remove the last obstacle to removing CONFIG_PHYSICAL_START
on x86_64.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86_64/Kconfig  |    4 +++
 arch/x86_64/Makefile |   10 +++++++
 scripts/Makefile     |   11 ++++---
 scripts/mketrel.c    |   70 ++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 90 insertions(+), 5 deletions(-)
 create mode 100644 scripts/mketrel.c

diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index 16d9bf3..773b487 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64
 	bool
 	default n
 
+config ELF_RELOCATABLE
+	bool
+	default y
+
 source "init/Kconfig"
 
 
diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile
index 9dd91b2..5ae79ab 100644
--- a/arch/x86_64/Makefile
+++ b/arch/x86_64/Makefile
@@ -124,6 +124,16 @@ define archhelp
   echo  '  isoimage     - Create a boot CD-ROM image'
 endef
 
+ifeq ($(CONFIG_RELOCATABLE),y)
+define cmd_vmlinux__
+      $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
+      -T $(vmlinux-lds) $(vmlinux-init)		\
+      --start-group $(vmlinux-main) --end-group	\
+      $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \
+      && scripts/mketrel $@
+endef
+endif
+
 CLEAN_FILES += arch/$(ARCH)/boot/fdimage \
 	       arch/$(ARCH)/boot/image.iso \
 	       arch/$(ARCH)/boot/mtools.conf
diff --git a/scripts/Makefile b/scripts/Makefile
index 1c73c5a..ddba550 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -7,11 +7,12 @@
 # conmakehash:   Create chartable
 # conmakehash:	 Create arrays for initializing the kernel console tables
 
-hostprogs-$(CONFIG_KALLSYMS)     += kallsyms
-hostprogs-$(CONFIG_LOGO)         += pnmtologo
-hostprogs-$(CONFIG_VT)           += conmakehash
-hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash
-hostprogs-$(CONFIG_IKCONFIG)     += bin2c
+hostprogs-$(CONFIG_KALLSYMS)        += kallsyms
+hostprogs-$(CONFIG_LOGO)            += pnmtologo
+hostprogs-$(CONFIG_VT)              += conmakehash
+hostprogs-$(CONFIG_PROM_CONSOLE)    += conmakehash
+hostprogs-$(CONFIG_IKCONFIG)        += bin2c
+hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel
 
 always		:= $(hostprogs-y) $(hostprogs-m)
 
diff --git a/scripts/mketrel.c b/scripts/mketrel.c
new file mode 100644
index 0000000..effa312
--- /dev/null
+++ b/scripts/mketrel.c
@@ -0,0 +1,70 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <elf.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+#include <stdarg.h>
+#include <stdlib.h>
+
+static int fd;
+unsigned char e_ident[EI_NIDENT];
+
+void die(const char * str, ...)
+{
+	va_list args;
+	va_start(args, str);
+	vfprintf(stderr, str, args);
+	fputc('\n', stderr);
+	exit(1);
+}
+
+void file_open(const char *name)
+{
+	if ((fd = open(name, O_RDWR, 0)) < 0)
+		die("Unable to open `%s': %m", name);
+}
+
+static void mketrel(void)
+{
+	unsigned char e_type[2];
+	if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident))
+		die("Cannot read ELF header: %s\n", strerror(errno));
+
+	if (memcmp(e_ident, ELFMAG, 4) != 0)
+		die("No ELF magic\n");
+
+	if ((e_ident[EI_CLASS] != ELFCLASS64) &&
+	    (e_ident[EI_CLASS] != ELFCLASS32))
+		die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]);
+	
+	if ((e_ident[EI_DATA] != ELFDATA2LSB) &&
+	    (e_ident[EI_DATA] != ELFDATA2MSB))
+		die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]);
+
+	if (e_ident[EI_VERSION] != EV_CURRENT)
+		die("Unknown ELF version: %d\n", e_ident[EI_VERSION]);
+
+	if (e_ident[EI_DATA] == ELFDATA2LSB) {
+		e_type[0] = ET_REL & 0xff;
+		e_type[1] = ET_REL >> 8;
+	} else {
+		e_type[1] = ET_REL & 0xff;
+		e_type[0] = ET_REL >> 8;
+	}
+
+	if (write(fd, &e_type, sizeof(e_type)) != sizeof(e_type))
+		die("Cannot write ELF type: %s\n", strerror(errno));
+}
+
+int main(int argc, char **argv)
+{
+	if (argc != 2)
+		die("Usage: mketrel: vmlinux");
+	file_open(argv[1]);
+	mketrel();
+	close(fd);
+	return 0;
+}
-- 
1.5.1.1.181.g2de0


^ permalink raw reply related	[flat|nested] 34+ messages in thread

* [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
@ 2007-04-23  5:12                       ` Eric W. Biederman
  0 siblings, 0 replies; 34+ messages in thread
From: Eric W. Biederman @ 2007-04-23  5:12 UTC (permalink / raw)
  To: Andrew Morton, Andi Kleen
  Cc: fastboot, Horms, linux-kernel, Kexec Mailing List, Helge Hafting,
	thunder7, Magnus Damm, vgoyal


Currently because vmlinux does not reflect that the kernel is relocatable
we still have to support CONFIG_PHYSICAL_START.  So this patch adds a small
c program to do what we cannot do with a linker script, set the elf header
type to ET_DYN.

This should remove the last obstacle to removing CONFIG_PHYSICAL_START
on x86_64.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 arch/x86_64/Kconfig  |    4 +++
 arch/x86_64/Makefile |   10 +++++++
 scripts/Makefile     |   11 ++++---
 scripts/mketrel.c    |   70 ++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 90 insertions(+), 5 deletions(-)
 create mode 100644 scripts/mketrel.c

diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index 16d9bf3..773b487 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64
 	bool
 	default n
 
+config ELF_RELOCATABLE
+	bool
+	default y
+
 source "init/Kconfig"
 
 
diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile
index 9dd91b2..5ae79ab 100644
--- a/arch/x86_64/Makefile
+++ b/arch/x86_64/Makefile
@@ -124,6 +124,16 @@ define archhelp
   echo  '  isoimage     - Create a boot CD-ROM image'
 endef
 
+ifeq ($(CONFIG_RELOCATABLE),y)
+define cmd_vmlinux__
+      $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
+      -T $(vmlinux-lds) $(vmlinux-init)		\
+      --start-group $(vmlinux-main) --end-group	\
+      $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \
+      && scripts/mketrel $@
+endef
+endif
+
 CLEAN_FILES += arch/$(ARCH)/boot/fdimage \
 	       arch/$(ARCH)/boot/image.iso \
 	       arch/$(ARCH)/boot/mtools.conf
diff --git a/scripts/Makefile b/scripts/Makefile
index 1c73c5a..ddba550 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -7,11 +7,12 @@
 # conmakehash:   Create chartable
 # conmakehash:	 Create arrays for initializing the kernel console tables
 
-hostprogs-$(CONFIG_KALLSYMS)     += kallsyms
-hostprogs-$(CONFIG_LOGO)         += pnmtologo
-hostprogs-$(CONFIG_VT)           += conmakehash
-hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash
-hostprogs-$(CONFIG_IKCONFIG)     += bin2c
+hostprogs-$(CONFIG_KALLSYMS)        += kallsyms
+hostprogs-$(CONFIG_LOGO)            += pnmtologo
+hostprogs-$(CONFIG_VT)              += conmakehash
+hostprogs-$(CONFIG_PROM_CONSOLE)    += conmakehash
+hostprogs-$(CONFIG_IKCONFIG)        += bin2c
+hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel
 
 always		:= $(hostprogs-y) $(hostprogs-m)
 
diff --git a/scripts/mketrel.c b/scripts/mketrel.c
new file mode 100644
index 0000000..effa312
--- /dev/null
+++ b/scripts/mketrel.c
@@ -0,0 +1,70 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <elf.h>
+#include <stdio.h>
+#include <errno.h>
+#include <string.h>
+#include <stdarg.h>
+#include <stdlib.h>
+
+static int fd;
+unsigned char e_ident[EI_NIDENT];
+
+void die(const char * str, ...)
+{
+	va_list args;
+	va_start(args, str);
+	vfprintf(stderr, str, args);
+	fputc('\n', stderr);
+	exit(1);
+}
+
+void file_open(const char *name)
+{
+	if ((fd = open(name, O_RDWR, 0)) < 0)
+		die("Unable to open `%s': %m", name);
+}
+
+static void mketrel(void)
+{
+	unsigned char e_type[2];
+	if (read(fd, &e_ident, sizeof(e_ident)) != sizeof(e_ident))
+		die("Cannot read ELF header: %s\n", strerror(errno));
+
+	if (memcmp(e_ident, ELFMAG, 4) != 0)
+		die("No ELF magic\n");
+
+	if ((e_ident[EI_CLASS] != ELFCLASS64) &&
+	    (e_ident[EI_CLASS] != ELFCLASS32))
+		die("Unrecognized ELF class: %x\n", e_ident[EI_CLASS]);
+	
+	if ((e_ident[EI_DATA] != ELFDATA2LSB) &&
+	    (e_ident[EI_DATA] != ELFDATA2MSB))
+		die("Unrecognized ELF data encoding: %x\n", e_ident[EI_DATA]);
+
+	if (e_ident[EI_VERSION] != EV_CURRENT)
+		die("Unknown ELF version: %d\n", e_ident[EI_VERSION]);
+
+	if (e_ident[EI_DATA] == ELFDATA2LSB) {
+		e_type[0] = ET_REL & 0xff;
+		e_type[1] = ET_REL >> 8;
+	} else {
+		e_type[1] = ET_REL & 0xff;
+		e_type[0] = ET_REL >> 8;
+	}
+
+	if (write(fd, &e_type, sizeof(e_type)) != sizeof(e_type))
+		die("Cannot write ELF type: %s\n", strerror(errno));
+}
+
+int main(int argc, char **argv)
+{
+	if (argc != 2)
+		die("Usage: mketrel: vmlinux");
+	file_open(argv[1]);
+	mketrel();
+	close(fd);
+	return 0;
+}
-- 
1.5.1.1.181.g2de0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2007-06-01 12:26 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-30 15:12 [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header Eric W. Biederman
2007-04-30 15:12 ` Eric W. Biederman
2007-04-30 15:17 ` Andi Kleen
2007-04-30 15:17   ` Andi Kleen
2007-05-01  3:55   ` Vivek Goyal
2007-05-01  3:55     ` Vivek Goyal
2007-05-01  4:20     ` Eric W. Biederman
2007-05-01  4:20       ` Eric W. Biederman
2007-05-01  5:06       ` Vivek Goyal
2007-05-01  5:06         ` Vivek Goyal
2007-05-01  5:26         ` Eric W. Biederman
2007-05-01  5:26           ` Eric W. Biederman
2007-05-01  6:25           ` Andi Kleen
2007-05-01  6:25             ` Andi Kleen
2007-05-01  5:54             ` Eric W. Biederman
2007-05-01  5:54               ` Eric W. Biederman
2007-05-01  6:44               ` Vivek Goyal
2007-05-01  6:44                 ` Vivek Goyal
2007-05-28 10:54         ` Bernhard Walle
2007-05-28 10:54           ` Bernhard Walle
2007-05-28 11:09           ` Vivek Goyal
2007-05-28 11:09             ` Vivek Goyal
2007-05-28 14:39             ` Bernhard Walle
2007-05-28 14:39               ` Bernhard Walle
2007-06-01 12:26               ` Bernhard Walle
2007-06-01 12:26                 ` Bernhard Walle
2007-05-28 14:57           ` Andi Kleen
2007-05-28 14:57             ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2007-03-31  7:53 2.6.21-rc5-mm3 - no boot, "address not 2M aligned" Andrew Morton
2007-04-01  5:29 ` thunder7
2007-04-01  6:15   ` Eric W. Biederman
2007-04-01  6:29     ` Andrew Morton
2007-04-02  7:41       ` Vivek Goyal
2007-04-02  8:43         ` Eric W. Biederman
2007-04-02  9:45           ` Vivek Goyal
2007-04-02 17:26             ` Eric W. Biederman
2007-04-03  4:01               ` Vivek Goyal
2007-04-03  5:23                 ` Eric W. Biederman
2007-04-03 10:03                   ` Vivek Goyal
2007-04-23  5:12                     ` [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header Eric W. Biederman
2007-04-23  5:12                       ` Eric W. Biederman
2007-04-24  6:31                       ` Vivek Goyal
2007-04-24  6:31                         ` Vivek Goyal
2007-04-24  7:21                         ` Eric W. Biederman
2007-04-24  7:21                           ` Eric W. Biederman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.