[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Ard Biesheuvel]

This series applies on top of today's -next, and addresses an issue with
the new kallsyms code that is queued there, that enables base relative
kallsyms tables for all architectures (except IA-64)

Two issues have surfaced on ARM with the new kallsyms code:
a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
   relative kallsyms code to reach it;
b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
   as is the case for kernels that execute from RAM, resulting in symbols
   that are out of range.

Since the way kallsyms deals with XIP kernels on ARM leaves some room for
improvement regardless of the base relative changes, this series proposes
a fix that allows the special case to be removed from the kallsyms handling
entirely.

Patch #1 moves the .stubs and .vectors section back into the kernel VMA, while
preserving the guaranteed virtual offset of 4 KB. This results in all symbols
that kallsyms sees to be in a reasonable interval.

Patch #2 removes the special case for CONFIG_ARM && !CONFIG_XIP_KERNEL in the
invocation of scripts/kallsyms

Patch #3 removes the now unused --page-offset command line argument handling
from scripts/kallsyms.c

Note that we may still need to remove ARM from the list of architectures that
support base relative kallsyms tables if we cannot fix issue a) above, but
removing this special case seemed like an obvious improvement to me.

Ard Biesheuvel (3):
  ARM: move .vectors and .stubs sections back into the kernel VMA
  kallsyms: remove special lower address limit for CONFIG_ARM
  kallsyms: remove --page-offset command line option

 arch/arm/kernel/entry-armv.S  |  7 +++--
 arch/arm/kernel/vmlinux.lds.S | 15 ++++++-----
 scripts/kallsyms.c            | 27 ++++----------------
 scripts/link-vmlinux.sh       |  4 ---
 4 files changed, 16 insertions(+), 37 deletions(-)

-- 
2.5.0

[PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA

[Ard Biesheuvel]

Commit b9b32bf70f2f ("ARM: use linker magic for vectors and vector stubs")
updated the linker script to emit the .vectors and .stubs sections into a
VMA range that is zero based and disjoint from the normal static kernel
region. The reason for that was that this way, the sections can be placed
exactly 4 KB apart, while the payload of the .vectors section is only 32
bytes.

Since the symbols that are part of the .stubs section are emitted into the
kallsyms table, they appear with zero based addresses as well, e.g.,

  00000000 t __vectors_start
  00001000 t __stubs_start
  00001004 t vector_rst
  00001020 t vector_irq
  000010a0 t vector_dabt
  00001120 t vector_pabt
  000011a0 t vector_und
  00001220 t vector_addrexcptn
  00001240 t vector_fiq
  00001240 T vector_fiq_offset

As this confuses perf when it accesses the kallsyms tables, commit
7122c3e9154b ("scripts/link-vmlinux.sh: only filter kernel symbols for
arm") implemented a somewhat ugly special case for ARM, where the value
of CONFIG_PAGE_OFFSET is passed to scripts/kallsyms, and symbols whose
address is below it are filtered out. Note that this special case only
applies to CONFIG_XIP_KERNEL=n, not because the issue the patch addresses
exists only in that case, but because finding a limit below which to apply
the filtering is too difficult.

Since the constraint we are trying to meet here is that the .vectors
section lives exactly 4 KB before the .stubs section, regardless of the
absolute addresses of either (since relative branches are used to jump from
the vector table to the stubs), we can simply emit the .stubs section as
part of the kernel VMA, and place the .vectors section 4 KB before it using
an explicit VMA override. By doing that, and renaming the __vectors_start
symbol that is local to arch/arm/kernel/entry-armv.S (not the one in the
linker script), the kallsyms table looks somewhat sane, regardless of
whether CONFIG_XIP_KERNEL is set, and we can drop the special case in
scripts/kallsyms entirely. E.g.,

  00001240 A vector_fiq_offset
  ...
  c0c35000 T __init_begin
  c0c35000 t __stubs_start
  c0c35000 T __stubs_start
  c0c35004 t vector_rst
  c0c35020 t vector_irq
  c0c350a0 t vector_dabt
  c0c35120 t vector_pabt
  c0c351a0 t vector_und
  c0c35220 t vector_addrexcptn
  c0c35240 T vector_fiq
  c0c352c0 T __stubs_end
  c0c352c0 T __vectors_start
  c0c352e0 t __mmap_switched
  c0c352e0 T _sinittext
  c0c352e0 T __vectors_end

(Note that vector_fiq_offset is now an absolute symbol, which kallsyms
already ignores by default)

The sections themselves are emitted 4 KB apart, as required:
  ...
  [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
  [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
  ...

and the relative branches in the .vectors section still point to the
right place:

  c0c34000 <.vectors>:
  c0c34000:       f001 b800       b.w     c0c35004 <vector_rst>
  c0c34004:       f001 b8cc       b.w     c0c351a0 <vector_und>
  c0c34008:       f8df fff4       ldr.w   pc, [pc, #4084] ; c0c35000
  c0c3400c:       f001 b888       b.w     c0c35120 <vector_pabt>
  c0c34010:       f001 b846       b.w     c0c350a0 <vector_dabt>
  c0c34014:       f001 b904       b.w     c0c35220 <vector_addrexcptn>
  c0c34018:       f001 b802       b.w     c0c35020 <vector_irq>
  c0c3401c:       f001 b910       b.w     c0c35240 <vector_fiq>

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm/kernel/entry-armv.S  |  7 +++----
 arch/arm/kernel/vmlinux.lds.S | 15 ++++++++-------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 3ce377f7251f..8575ff42c0d4 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1202,14 +1202,13 @@ vector_addrexcptn:
 	.long	__fiq_svc			@  e
 	.long	__fiq_svc			@  f
 
-	.globl	vector_fiq_offset
-	.equ	vector_fiq_offset, vector_fiq
+	.globl	vector_fiq
 
 	.section .vectors, "ax", %progbits
-__vectors_start:
+.L__vectors_start:
 	W(b)	vector_rst
 	W(b)	vector_und
-	W(ldr)	pc, __vectors_start + 0x1000
+	W(ldr)	pc, .L__vectors_start + 0x1000
 	W(b)	vector_pabt
 	W(b)	vector_dabt
 	W(b)	vector_addrexcptn
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde5ce48..7160658fd5d4 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -164,19 +164,20 @@ SECTIONS
 	 * The vectors and stubs are relocatable code, and the
 	 * only thing that matters is their relative offsets
 	 */
+	__stubs_start = .;
+	.stubs : {
+		*(.stubs)
+	}
+	__stubs_end = .;
+
 	__vectors_start = .;
-	.vectors 0 : AT(__vectors_start) {
+	.vectors ADDR(.stubs) - 0x1000 : AT(__vectors_start) {
 		*(.vectors)
 	}
 	. = __vectors_start + SIZEOF(.vectors);
 	__vectors_end = .;
 
-	__stubs_start = .;
-	.stubs 0x1000 : AT(__stubs_start) {
-		*(.stubs)
-	}
-	. = __stubs_start + SIZEOF(.stubs);
-	__stubs_end = .;
+	vector_fiq_offset = vector_fiq - ADDR(.vectors);
 
 	INIT_TEXT_SECTION(8)
 	.exit.text : {
-- 
2.5.0

[PATCH 2/3] kallsyms: remove special lower address limit for CONFIG_ARM

[Ard Biesheuvel]

Now that we no longer emit .stubs symbols into a section VMA loaded
at absolute address 0x1000, we can drop the ARM-specific override that
sets a lower limit based on CONFIG_PAGE_OFFSET, below which symbols are
filtered from the kallsyms output.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 scripts/link-vmlinux.sh | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index aae2473301ea..b83f918c7830 100755
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -82,10 +82,6 @@ kallsyms()
 		kallsymopt="${kallsymopt} --all-symbols"
 	fi
 
-	if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n "${CONFIG_PAGE_OFFSET}" ]; then
-		kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
-	fi
-
 	if [ -n "${CONFIG_X86_64}" ] && [ -n "${CONFIG_SMP}" ]; then
 		kallsymopt="${kallsymopt} --absolute-percpu"
 	fi
-- 
2.5.0

[PATCH 3/3] kallsyms: remove --page-offset command line option

[Ard Biesheuvel]

The --page-offset command line option was only used for ARM, to filter
symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
remove the functionality altogether.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 scripts/kallsyms.c | 27 ++++----------------
 1 file changed, 5 insertions(+), 22 deletions(-)

diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
index 02473b71643b..ce36fc02fe8c 100644
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@ -63,7 +63,6 @@ static unsigned int table_size, table_cnt;
 static int all_symbols = 0;
 static int absolute_percpu = 0;
 static char symbol_prefix_char = '\0';
-static unsigned long long kernel_start_addr = 0;
 static int base_relative = 0;
 
 int token_profit[0x10000];
@@ -229,9 +228,6 @@ static int symbol_valid(struct sym_entry *s)
 	char *sym_name = (char *)s->sym + 1;
 
 
-	if (s->addr < kernel_start_addr)
-		return 0;
-
 	/* skip prefix char */
 	if (symbol_prefix_char && *sym_name == symbol_prefix_char)
 		sym_name++;
@@ -742,21 +738,11 @@ static void record_relative_base(void)
 {
 	unsigned int i;
 
-	if (kernel_start_addr > 0) {
-		/*
-		 * If the kernel start address was specified, use that as
-		 * the relative base rather than going through the table,
-		 * since it should be a reasonable default, and values below
-		 * it will be ignored anyway.
-		 */
-		relative_base = kernel_start_addr;
-	} else {
-		relative_base = -1ULL;
-		for (i = 0; i < table_cnt; i++)
-			if (!symbol_absolute(&table[i]) &&
-			    table[i].addr < relative_base)
-				relative_base = table[i].addr;
-	}
+	relative_base = -1ULL;
+	for (i = 0; i < table_cnt; i++)
+		if (!symbol_absolute(&table[i]) &&
+		    table[i].addr < relative_base)
+			relative_base = table[i].addr;
 }
 
 int main(int argc, char **argv)
@@ -774,9 +760,6 @@ int main(int argc, char **argv)
 				if ((*p == '"' && *(p+2) == '"') || (*p == '\'' && *(p+2) == '\''))
 					p++;
 				symbol_prefix_char = *p;
-			} else if (strncmp(argv[i], "--page-offset=", 14) == 0) {
-				const char *p = &argv[i][14];
-				kernel_start_addr = strtoull(p, NULL, 16);
 			} else if (strcmp(argv[i], "--base-relative") == 0)
 				base_relative = 1;
 			else
-- 
2.5.0

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Nicolas Pitre]

On Tue, 2 Feb 2016, Ard Biesheuvel wrote:

> This series applies on top of today's -next, and addresses an issue with
> the new kallsyms code that is queued there, that enables base relative
> kallsyms tables for all architectures (except IA-64)
> 
> Two issues have surfaced on ARM with the new kallsyms code:
> a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
>    relative kallsyms code to reach it;
> b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
>    as is the case for kernels that execute from RAM, resulting in symbols
>    that are out of range.
> 
> Since the way kallsyms deals with XIP kernels on ARM leaves some room for
> improvement regardless of the base relative changes, this series proposes
> a fix that allows the special case to be removed from the kallsyms handling
> entirely.
> 
> Patch #1 moves the .stubs and .vectors section back into the kernel VMA, while
> preserving the guaranteed virtual offset of 4 KB. This results in all symbols
> that kallsyms sees to be in a reasonable interval.
> 
> Patch #2 removes the special case for CONFIG_ARM && !CONFIG_XIP_KERNEL in the
> invocation of scripts/kallsyms
> 
> Patch #3 removes the now unused --page-offset command line argument handling
> from scripts/kallsyms.c
> 
> Note that we may still need to remove ARM from the list of architectures that
> support base relative kallsyms tables if we cannot fix issue a) above, but
> removing this special case seemed like an obvious improvement to me.

For those 3 patches:

Acked-by: Nicolas Pitre <nico@linaro.org>



> 
> Ard Biesheuvel (3):
>   ARM: move .vectors and .stubs sections back into the kernel VMA
>   kallsyms: remove special lower address limit for CONFIG_ARM
>   kallsyms: remove --page-offset command line option
> 
>  arch/arm/kernel/entry-armv.S  |  7 +++--
>  arch/arm/kernel/vmlinux.lds.S | 15 ++++++-----
>  scripts/kallsyms.c            | 27 ++++----------------
>  scripts/link-vmlinux.sh       |  4 ---
>  4 files changed, 16 insertions(+), 37 deletions(-)
> 
> -- 
> 2.5.0
> 
> 

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Chris Brandt]

On Tue, 2 Feb 2016, Ard Biesheuvel wrote:

> This series applies on top of today's -next, and addresses an issue 
> with the new kallsyms code that is queued there, that enables base 
> relative kallsyms tables for all architectures (except IA-64)
> 
> Two issues have surfaced on ARM with the new kallsyms code:
> a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
>    relative kallsyms code to reach it;
> b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
>    as is the case for kernels that execute from RAM, resulting in symbols
>    that are out of range.


For whatever it's worth:


I applied my XIP_KERNEL fixes (for ARMv7) on top of -next and attempted to boot which resulted in a flood of these:

  "Unable to handle kernel NULL pointer dereference at virtual address 00000000"

and of course it dies.


I then applied the 3 patches and tried again and this time it booted up....almost.
It looks like it makes it all the way up to when it is going to mount my rootfs, but then dies.

My kernel (.text) starts at 0xbf000000 (MODULES_VADDR), so the "LR is at 0xb6f87e88" is obviously bad.


Chris



================ boot log ======================


VFS: Mounted root (squashfs filesystem) readonly on device 31:0.
devtmpfs: mounted
Freeing unused kernel memory: 36K (c000a000 - c0013000)
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c05f0000
[00000000] *pgd=205f5831, *pte=00000000, *ppte=00000000
Internal error: Oops: 80000007 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: init Not tainted 4.5.0-rc2-next-20160202-dirty #3
Hardware name: Generic R7S72100 (Flattened Device Tree)
task: c0613000 ti: c0614000 task.ti: c0614000
PC is at 0x0
LR is at 0xb6f87e88
pc : [<00000000>]    lr : [<b6f87e88>]    psr: 80000093
sp : c0615ff8  ip : 00000054  fp : beca8ba4
r10: b6f8b9ab  r9 : 00000000  r8 : 00000014
r7 : 000000c0  r6 : b6f93f74  r5 : 00000000  r4 : ffffffff
r3 : 04000022  r2 : 00000003  r1 : 00001000  r0 : 00000000
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 18c5347d  Table: 205f0059  DAC: 00000055
Process init (pid: 1, stack limit = 0xc0614208)
Stack: (0xc0615ff8 to 0xc0616000)
5fe0:                                                       fde4be6f 89031a8e
Backtrace: invalid frame pointer 0xbeca8ba4
Code: bad PC value
---[ end trace ed7071b866b0f003 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Ard Biesheuvel]

On 2 February 2016 at 19:59, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On Tue, 2 Feb 2016, Ard Biesheuvel wrote:
>
>> This series applies on top of today's -next, and addresses an issue
>> with the new kallsyms code that is queued there, that enables base
>> relative kallsyms tables for all architectures (except IA-64)
>>
>> Two issues have surfaced on ARM with the new kallsyms code:
>> a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
>>    relative kallsyms code to reach it;
>> b) CONFIG_XIP_KERNEL=y kernel symbols are not filtered against PAGE_OFFSET,
>>    as is the case for kernels that execute from RAM, resulting in symbols
>>    that are out of range.
>
>
> For whatever it's worth:
>
>
> I applied my XIP_KERNEL fixes (for ARMv7) on top of -next and attempted to boot which resulted in a flood of these:
>
>   "Unable to handle kernel NULL pointer dereference at virtual address 00000000"
>
> and of course it dies.
>
>
> I then applied the 3 patches and tried again and this time it booted up....almost.
> It looks like it makes it all the way up to when it is going to mount my rootfs, but then dies.
>
> My kernel (.text) starts at 0xbf000000 (MODULES_VADDR), so the "LR is at 0xb6f87e88" is obviously bad.
>
>
> ================ boot log ======================
>
>
> VFS: Mounted root (squashfs filesystem) readonly on device 31:0.
> devtmpfs: mounted
> Freeing unused kernel memory: 36K (c000a000 - c0013000)
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = c05f0000
> [00000000] *pgd=205f5831, *pte=00000000, *ppte=00000000
> Internal error: Oops: 80000007 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: init Not tainted 4.5.0-rc2-next-20160202-dirty #3
> Hardware name: Generic R7S72100 (Flattened Device Tree)
> task: c0613000 ti: c0614000 task.ti: c0614000
> PC is at 0x0
> LR is at 0xb6f87e88
> pc : [<00000000>]    lr : [<b6f87e88>]    psr: 80000093
> sp : c0615ff8  ip : 00000054  fp : beca8ba4
> r10: b6f8b9ab  r9 : 00000000  r8 : 00000014
> r7 : 000000c0  r6 : b6f93f74  r5 : 00000000  r4 : ffffffff
> r3 : 04000022  r2 : 00000003  r1 : 00001000  r0 : 00000000
> Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
> Control: 18c5347d  Table: 205f0059  DAC: 00000055
> Process init (pid: 1, stack limit = 0xc0614208)
> Stack: (0xc0615ff8 to 0xc0616000)
> 5fe0:                                                       fde4be6f 89031a8e
> Backtrace: invalid frame pointer 0xbeca8ba4
> Code: bad PC value
> ---[ end trace ed7071b866b0f003 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
>

Are you getting any warnings/errors during the build?

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Chris Brandt]

> Are you getting any warnings/errors during the build?

Nothing. The build was clean.


And just to be safe, I did make clean, then make xipImage and re-flashed again.
Same result.


I'll see if I can step through and see exactly where it's dying.
I realize that no one really care about or tests XIP_KERNEL with ARMv7 at the moment, so I'll have to figure it out that some point. I just thought I'd let you know.


Chris

[PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA

[Russell King - ARM Linux]

On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
> The sections themselves are emitted 4 KB apart, as required:
>   ...
>   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
>   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
>   ...

... which means we end up wasting most of a page for absolutely no
purpose what so ever.  Sorry, I'm really not happy about this
gratuitous wastage.

We changed to the existing solution to get rid of the VMA offset
to make the code easier to read, but if we're going to get rid of
that improvement, just revert the change.  (Check the kernel history.)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 3/3] kallsyms: remove --page-offset command line option

[Russell King - ARM Linux]

On Tue, Feb 02, 2016 at 02:19:34PM +0100, Ard Biesheuvel wrote:
> The --page-offset command line option was only used for ARM, to filter
> symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
> remove the functionality altogether.

>From what I remember, this option has nothing to do with MMU-ful ARM,
but noMMU ARM, where the .text segment can be significantly different
from the .data segment.

I think you need to talk to noMMU people about this patch.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA

[Nicolas Pitre]

On Wed, 3 Feb 2016, Russell King - ARM Linux wrote:

> On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
> > The sections themselves are emitted 4 KB apart, as required:
> >   ...
> >   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
> >   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
> >   ...
> 
> ... which means we end up wasting most of a page for absolutely no
> purpose what so ever.  Sorry, I'm really not happy about this
> gratuitous wastage.

In practice this shouldn't make much of a difference given zImage is 
compressed and large zero filled areas compress very well.

But this is not nice for XIP though.


Nicolas

[PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA

[Ard Biesheuvel]

On 3 February 2016 at 01:03, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
>> The sections themselves are emitted 4 KB apart, as required:
>>   ...
>>   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
>>   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
>>   ...
>
> ... which means we end up wasting most of a page for absolutely no
> purpose what so ever.  Sorry, I'm really not happy about this
> gratuitous wastage.
>

No, we don't. Here's some more context:

Before:
  [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
  [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
  [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
  [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
  [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32

After
  [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
  [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
  [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
  [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
  [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32

As you can see, the LMA footprint has not increased, only .stubs and
.vectors have been reordered. The apparent rounding after the .notes
section occurs in both cases, and is due to the fact that __init_begin
is rounded to page size, and has nothing to do with the VMAs chosen
for the .stubs and .vectors section.

> We changed to the existing solution to get rid of the VMA offset
> to make the code easier to read, but if we're going to get rid of
> that improvement, just revert the change.  (Check the kernel history.)
>

I think that change was an improvement. It makes the code itself more
readable, but also results in correct references in the object files
rather than opaque expressions, i.e.,

  c0c34000 <.vectors>:
  c0c34000:       f001 b800       b.w     c0c35004 <vector_rst>
  c0c34004:       f001 b8cc       b.w     c0c351a0 <vector_und>
  c0c34008:       f8df fff4       ldr.w   pc, [pc, #4084] ; c0c35000
  c0c3400c:       f001 b888       b.w     c0c35120 <vector_pabt>
  c0c34010:       f001 b846       b.w     c0c350a0 <vector_dabt>
  c0c34014:       f001 b904       b.w     c0c35220 <vector_addrexcptn>
  c0c34018:       f001 b802       b.w     c0c35020 <vector_irq>
  c0c3401c:       f001 b910       b.w     c0c35240 <vector_fiq>

-- 
Ard.

[PATCH 3/3] kallsyms: remove --page-offset command line option

[Ard Biesheuvel]

(+ Uwe, Maxime)

Complete thread here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/474400

On 3 February 2016 at 01:05, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 02, 2016 at 02:19:34PM +0100, Ard Biesheuvel wrote:
>> The --page-offset command line option was only used for ARM, to filter
>> symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
>> remove the functionality altogether.
>
> From what I remember, this option has nothing to do with MMU-ful ARM,
> but noMMU ARM, where the .text segment can be significantly different
> from the .data segment.
>
> I think you need to talk to noMMU people about this patch.
>

We have

commit f6537f2f0eba4eba3354e48dbe3047db6d8b6254
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Sat Nov 2 09:11:33 2013 +1030

    scripts/kallsyms: filter symbols not in kernel address space

    This patch uses CONFIG_PAGE_OFFSET to filter symbols which
    are not in kernel address space because these symbols are
    generally for generating code purpose and can't be run at
    kernel mode, so we needn't keep them in /proc/kallsyms.

    For example, on ARM there are some symbols which may be
    linked in relocatable code section, then perf can't parse
    symbols any more from /proc/kallsyms, this patch fixes the
    problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da)

which introduces the --page-offset option to kallsyms, in response to
your patch that moves .vectors and .stubs to VMA 0x0. Then we have

commit 7122c3e9154b5d9a7422f68f02d8acf050fad2b0
Author: Ming Lei <tom.leiming@gmail.com>
Date:   Tue Dec 10 16:46:29 2013 +1030

    scripts/link-vmlinux.sh: only filter kernel symbols for arm

    Actually CONFIG_PAGE_OFFSET isn't same with PAGE_OFFSET, so
    it isn't easy to figue out PAGE_OFFSET defined in header
    file from scripts.

    Because CONFIG_PAGE_OFFSET may not be defined in some ARCHs(
    64bit ARCH), or defined as bogus value in !MMU case, so
    this patch only applys the filter on ARM when CONFIG_PAGE_OFFSET
    is defined as the original problem is only on ARM.

which restricts the use of --page-offset to CONFIG_ARM, and

commit cc8475305203ddfd117b81e2e732194b67d8f310
Author: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Date:   Thu May 21 19:17:44 2015 +0800

    scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel

    When Kernel is executed in place from ROM, the symbol addresses can be
    lower than the page offset.

which restricts the use of --page-offset to CONFIG_ARM && !CONFIG_XIP_KERNEL

So it looks like the Dec 10 patch fixes some fallout related to !MMU
that was caused by the Nov 2 patch, but the original patch has nothing
to do with !MMU. Furthermore, 3 out of 4 !MMU configs we have in the
tree (efm32, stm32 and vf610m4) are also XIP kernel, for which
--page-offset isn't even used to begin with after Maxime's patch.
Hopefully Uwe and/or Maxime can confirm, but removing the PAGE_OFFSET
lower limit should not affect those platforms at all afaict,
especially since, after patch 1/3, there are no symbols left to filter
below that limit in the first place.

Thanks,
Ard.

[PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA

[Russell King - ARM Linux]

On Wed, Feb 03, 2016 at 08:56:35AM +0100, Ard Biesheuvel wrote:
> On 3 February 2016 at 01:03, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
> >> The sections themselves are emitted 4 KB apart, as required:
> >>   ...
> >>   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
> >>   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
> >>   ...
> >
> > ... which means we end up wasting most of a page for absolutely no
> > purpose what so ever.  Sorry, I'm really not happy about this
> > gratuitous wastage.
> >
> 
> No, we don't. Here's some more context:
> 
> Before:
>   [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
>   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
> 
> After
>   [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
>   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32

Meaningless numbers... Do you think you can quote with the header
please?  I don't tend to carry around the objdump headers in my head.
Thanks.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA

[Ard Biesheuvel]

On 3 February 2016 at 10:13, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Feb 03, 2016 at 08:56:35AM +0100, Ard Biesheuvel wrote:
>> On 3 February 2016 at 01:03, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Tue, Feb 02, 2016 at 02:19:32PM +0100, Ard Biesheuvel wrote:
>> >> The sections themselves are emitted 4 KB apart, as required:
>> >>   ...
>> >>   [16] .stubs       PROGBITS   c0c35000 a35000 0002c0 00  AX  0   0 32
>> >>   [17] .vectors     PROGBITS   c0c34000 a44000 000020 00  AX  0   0  2
>> >>   ...
>> >
>> > ... which means we end up wasting most of a page for absolutely no
>> > purpose what so ever.  Sorry, I'm really not happy about this
>> > gratuitous wastage.
>> >
>>
>> No, we don't. Here's some more context:
>>
>> Before:
>>   [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
>>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>>   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
>>   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
>>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
>>
>> After
>>   [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
>>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>>   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
>>   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
>>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
>
> Meaningless numbers... Do you think you can quote with the header
> please?  I don't tend to carry around the objdump headers in my head.
> Thanks.
>

BEFORE

$ readelf -S vmlinux
There are 34 section headers, starting at offset 0x10a6e60:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .head.text        PROGBITS        c0208000 008000 000268 00  AX  0   0  4
  [ 2] .text             PROGBITS        c0209000 009000 5d6e7c 00  AX
 0   0 4096
  [ 3] .fixup            PROGBITS        c07dfe7c 5dfe7c 000024 00  AX  0   0  4
  [ 4] .rodata           PROGBITS        c07e0000 5e0000 3ca310 00   A  0   0 64
  [ 5] __bug_table       PROGBITS        c0baa310 9aa310 0082c8 00   A  0   0  4
  [ 6] .pci_fixup        PROGBITS        c0bb25d8 9b25d8 001910 00   A  0   0  4
  [ 7] __ksymtab         PROGBITS        c0bb3ee8 9b3ee8 008a70 00   A  0   0  4
  [ 8] __ksymtab_gpl     PROGBITS        c0bbc958 9bc958 007d60 00   A  0   0  4
  [ 9] __ksymtab_strings PROGBITS        c0bc46b8 9c46b8 027c07 00   A  0   0  1
  [10] __param           PROGBITS        c0bec2c0 9ec2c0 0015b8 00   A  0   0  4
  [11] __modver          PROGBITS        c0bed878 9ed878 000788 00   A  0   0  4
  [12] __ex_table        PROGBITS        c0bee000 9ee000 001068 00   A  0   0  8
  [13] .ARM.unwind_idx   ARM_EXIDX       c0bef068 9ef068 03ff30 00  AL 18   0  4
  [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
  [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
  [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
  [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
  [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
  [19] .exit.text        PROGBITS        c0ca0498 ab0498 002f40 00  AX  0   0  4
  [20] .init.arch.info   PROGBITS        c0ca33d8 ab33d8 0026e8 00   A  0   0  8
  [21] .init.tagtable    PROGBITS        c0ca5ac0 ab5ac0 000048 00   A  0   0  4
  [22] .init.smpalt      PROGBITS        c0ca5b08 ab5b08 00dff8 00   A  0   0  4
  [23] .init.pv_table    PROGBITS        c0cb3b00 ac3b00 000a20 00   A  0   0  1
  [24] .init.data        PROGBITS        c0cb5000 ac5000 06de0c 00  WA
 0   0 4096
  [25] .data..percpu     PROGBITS        c0d23000 b33000 0049c0 00  WA  0   0 64
  [26] .data             PROGBITS        c0d28000 b38000 107d00 00  WA  0   0 64
  [27] .data..page_align PROGBITS        c0e30000 c40000 002000 00  WA
 0   0 4096
  [28] .bss              NOBITS          c0e32000 c42000 056ec8 00  WA  0   0 64
  [29] .comment          PROGBITS        00000000 c42000 00002d 01  MS  0   0  1
  [30] .ARM.attributes   ARM_ATTRIBUTES  00000000 c4202d 000033 00      0   0  1
  [31] .shstrtab         STRTAB          00000000 c42060 000165 00      0   0  1
  [32] .symtab           SYMTAB          00000000 c421c8 28f340 10
33 140990  4
  [33] .strtab           STRTAB          00000000 ed1508 1d5956 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

AFTER

$ readelf -S vmlinux
There are 34 section headers, starting at offset 0x10a6e50:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .head.text        PROGBITS        c0208000 008000 000268 00  AX  0   0  4
  [ 2] .text             PROGBITS        c0209000 009000 5d6e7c 00  AX
 0   0 4096
  [ 3] .fixup            PROGBITS        c07dfe7c 5dfe7c 000024 00  AX  0   0  4
  [ 4] .rodata           PROGBITS        c07e0000 5e0000 3ca310 00   A  0   0 64
  [ 5] __bug_table       PROGBITS        c0baa310 9aa310 0082c8 00   A  0   0  4
  [ 6] .pci_fixup        PROGBITS        c0bb25d8 9b25d8 001910 00   A  0   0  4
  [ 7] __ksymtab         PROGBITS        c0bb3ee8 9b3ee8 008a70 00   A  0   0  4
  [ 8] __ksymtab_gpl     PROGBITS        c0bbc958 9bc958 007d60 00   A  0   0  4
  [ 9] __ksymtab_strings PROGBITS        c0bc46b8 9c46b8 027c07 00   A  0   0  1
  [10] __param           PROGBITS        c0bec2c0 9ec2c0 0015b8 00   A  0   0  4
  [11] __modver          PROGBITS        c0bed878 9ed878 000788 00   A  0   0  4
  [12] __ex_table        PROGBITS        c0bee000 9ee000 001068 00   A  0   0  8
  [13] .ARM.unwind_idx   ARM_EXIDX       c0bef068 9ef068 03ff30 00  AL 18   0  4
  [14] .ARM.unwind_tab   PROGBITS        c0c2ef98 a2ef98 005088 00   A  0   0  4
  [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
  [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
  [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
  [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
  [19] .exit.text        PROGBITS        c0ca0498 ab0498 002f40 00  AX  0   0  4
  [20] .init.arch.info   PROGBITS        c0ca33d8 ab33d8 0026e8 00   A  0   0  8
  [21] .init.tagtable    PROGBITS        c0ca5ac0 ab5ac0 000048 00   A  0   0  4
  [22] .init.smpalt      PROGBITS        c0ca5b08 ab5b08 00dff8 00   A  0   0  4
  [23] .init.pv_table    PROGBITS        c0cb3b00 ac3b00 000a20 00   A  0   0  1
  [24] .init.data        PROGBITS        c0cb5000 ac5000 06de0c 00  WA
 0   0 4096
  [25] .data..percpu     PROGBITS        c0d23000 b33000 0049c0 00  WA  0   0 64
  [26] .data             PROGBITS        c0d28000 b38000 107d00 00  WA  0   0 64
  [27] .data..page_align PROGBITS        c0e30000 c40000 002000 00  WA
 0   0 4096
  [28] .bss              NOBITS          c0e32000 c42000 056ec8 00  WA  0   0 64
  [29] .comment          PROGBITS        00000000 c42000 00002d 01  MS  0   0  1
  [30] .ARM.attributes   ARM_ATTRIBUTES  00000000 c4202d 000033 00      0   0  1
  [31] .shstrtab         STRTAB          00000000 c42060 000165 00      0   0  1
  [32] .symtab           SYMTAB          00000000 c421c8 28f330 10
33 140988  4
  [33] .strtab           STRTAB          00000000 ed14f8 1d5956 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

[PATCH 3/3] kallsyms: remove --page-offset command line option

[Maxime Coquelin]

2016-02-03 9:16 GMT+01:00 Ard Biesheuvel <ard.biesheuvel@linaro.org>:
> (+ Uwe, Maxime)
>
> Complete thread here:
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/474400
>
> On 3 February 2016 at 01:05, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Tue, Feb 02, 2016 at 02:19:34PM +0100, Ard Biesheuvel wrote:
>>> The --page-offset command line option was only used for ARM, to filter
>>> symbol addresses below CONFIG_PAGE_OFFSET. This is no longer needed, so
>>> remove the functionality altogether.
>>
>> From what I remember, this option has nothing to do with MMU-ful ARM,
>> but noMMU ARM, where the .text segment can be significantly different
>> from the .data segment.
>>
>> I think you need to talk to noMMU people about this patch.
>>
>
> We have
>
> commit f6537f2f0eba4eba3354e48dbe3047db6d8b6254
> Author: Ming Lei <tom.leiming@gmail.com>
> Date:   Sat Nov 2 09:11:33 2013 +1030
>
>     scripts/kallsyms: filter symbols not in kernel address space
>
>     This patch uses CONFIG_PAGE_OFFSET to filter symbols which
>     are not in kernel address space because these symbols are
>     generally for generating code purpose and can't be run at
>     kernel mode, so we needn't keep them in /proc/kallsyms.
>
>     For example, on ARM there are some symbols which may be
>     linked in relocatable code section, then perf can't parse
>     symbols any more from /proc/kallsyms, this patch fixes the
>     problem (introduced b9b32bf70f2fb710b07c94e13afbc729afe221da)
>
> which introduces the --page-offset option to kallsyms, in response to
> your patch that moves .vectors and .stubs to VMA 0x0. Then we have
>
> commit 7122c3e9154b5d9a7422f68f02d8acf050fad2b0
> Author: Ming Lei <tom.leiming@gmail.com>
> Date:   Tue Dec 10 16:46:29 2013 +1030
>
>     scripts/link-vmlinux.sh: only filter kernel symbols for arm
>
>     Actually CONFIG_PAGE_OFFSET isn't same with PAGE_OFFSET, so
>     it isn't easy to figue out PAGE_OFFSET defined in header
>     file from scripts.
>
>     Because CONFIG_PAGE_OFFSET may not be defined in some ARCHs(
>     64bit ARCH), or defined as bogus value in !MMU case, so
>     this patch only applys the filter on ARM when CONFIG_PAGE_OFFSET
>     is defined as the original problem is only on ARM.
>
> which restricts the use of --page-offset to CONFIG_ARM, and
>
> commit cc8475305203ddfd117b81e2e732194b67d8f310
> Author: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Date:   Thu May 21 19:17:44 2015 +0800
>
>     scripts: link-vmlinux: Don't pass page offset to kallsyms if XIP Kernel
>
>     When Kernel is executed in place from ROM, the symbol addresses can be
>     lower than the page offset.
>
> which restricts the use of --page-offset to CONFIG_ARM && !CONFIG_XIP_KERNEL
>
> So it looks like the Dec 10 patch fixes some fallout related to !MMU
> that was caused by the Nov 2 patch, but the original patch has nothing
> to do with !MMU. Furthermore, 3 out of 4 !MMU configs we have in the
> tree (efm32, stm32 and vf610m4) are also XIP kernel, for which
> --page-offset isn't even used to begin with after Maxime's patch.
> Hopefully Uwe and/or Maxime can confirm, but removing the PAGE_OFFSET
> lower limit should not affect those platforms at all afaict,
> especially since, after patch 1/3, there are no symbols left to filter
> below that limit in the first place.

I agree with you, removing the PAGE_OFFSET lower limit should not
affect our platforms.

Regards,
Maxime

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Chris Brandt]

On 2 Feb 2016, Chris Brandt wrote:
> I then applied the 3 patches and tried again and this time it booted
> up....almost.
> It looks like it makes it all the way up to when it is going to mount
> my rootfs, but then dies.


I did some debugging, and here's why I'm crashing.


If you look at my System.map file, you'll see that I've got 2 "__stubs_start" symbols.

One at 0x bf353edc, the other at 0x bf353ee0.

bf353edc T __stubs_start
bf353edc T _etext
bf353ee0 t __stubs_start
bf353ee4 t vector_rst
bf353f00 t vector_irq
bf353f80 t vector_dabt
bf354000 t vector_pabt
bf354080 t vector_und
bf354100 t vector_addrexcptn
bf354120 T vector_fiq
bf3541a0 T __stubs_end
bf3541a0 T __vectors_start
bf3541c0 t __mmap_switched
bf3541c0 T __vectors_end


So, when you get to early_trap_init(), it grabs the first __stubs_start for the memcpy:

	memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - __stubs_start);


And when a printed out the destination, I get:

   Stubs at c09ff000 :00000000 BF006F20 EF9F0000 EA000064 etc...

Notice the first entry is 0....that's not right...and we know it's using that first __stubs_start symbol.


So, I hacked the code and put an offset of 4 like this:

	memcpy((void *)vectors + 0x1000, __stubs_start+4, __stubs_end - (__stubs_start+4));


And sure enough it booted fine.


So, why are there 2 __stubs_start symbols???
I haven't figured that one out yet.

And, I'm assuming you guys don't have 2 __stubs_start symbols either, correct?


Chris

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Ard Biesheuvel]

On 3 February 2016 at 14:33, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On 2 Feb 2016, Chris Brandt wrote:
>> I then applied the 3 patches and tried again and this time it booted
>> up....almost.
>> It looks like it makes it all the way up to when it is going to mount
>> my rootfs, but then dies.
>
>
> I did some debugging, and here's why I'm crashing.
>
>
> If you look at my System.map file, you'll see that I've got 2 "__stubs_start" symbols.
>
> One at 0x bf353edc, the other at 0x bf353ee0.
>
> bf353edc T __stubs_start

This is a global symbol

> bf353edc T _etext
> bf353ee0 t __stubs_start

This is a local symbol

> bf353ee4 t vector_rst
> bf353f00 t vector_irq
> bf353f80 t vector_dabt
> bf354000 t vector_pabt
> bf354080 t vector_und
> bf354100 t vector_addrexcptn
> bf354120 T vector_fiq
> bf3541a0 T __stubs_end
> bf3541a0 T __vectors_start
> bf3541c0 t __mmap_switched
> bf3541c0 T __vectors_end
>
>
> So, when you get to early_trap_init(), it grabs the first __stubs_start for the memcpy:
>
>         memcpy((void *)vectors + 0x1000, __stubs_start, __stubs_end - __stubs_start);
>

Indeed. It grabs the first one, which is the one defined by the linker script.

>
> And when a printed out the destination, I get:
>
>    Stubs at c09ff000 :00000000 BF006F20 EF9F0000 EA000064 etc...
>
> Notice the first entry is 0....that's not right...and we know it's using that first __stubs_start symbol.
>

The first quantity after __stubs_start should be the address of
vector_swi. Can you check if the second value coincides with that?

>
> So, I hacked the code and put an offset of 4 like this:
>
>         memcpy((void *)vectors + 0x1000, __stubs_start+4, __stubs_end - (__stubs_start+4));
>
>
> And sure enough it booted fine.
>
>
> So, why are there 2 __stubs_start symbols???
> I haven't figured that one out yet.
>

One defined by entry-armv.S and one defined by the linker script

> And, I'm assuming you guys don't have 2 __stubs_start symbols either, correct?
>

Yes, we do.

This is caused by the fact that __stubs_start is not aligned correctly on XIP.

Could you try this, please?

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 7160658fd5d4..a5b8e7b80d17 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -164,8 +164,8 @@ SECTIONS
         * The vectors and stubs are relocatable code, and the
         * only thing that matters is their relative offsets
         */
-       __stubs_start = .;
        .stubs : {
+               __stubs_start = .;
                *(.stubs)
        }
        __stubs_end = .;

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Chris Brandt]

On 2 Feb 2016, Chris Brandt wrote 
> > And when a printed out the destination, I get:
> >
> >    Stubs at c09ff000 :00000000 BF006F20 EF9F0000 EA000064 etc...
> >
> > Notice the first entry is 0....that's not right...and we know it's using that
> > first __stubs_start symbol.
> >
>
> The first quantity after __stubs_start should be the address of vector_swi. Can
>  you check if the second value coincides with that?

Yes, it does.

bf006f20 T vector_swi

Which is why it booted once I modified the start address.


> This is caused by the fact that __stubs_start is not aligned correctly on XIP.
>
> Could you try this, please?
>
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S index 7160658fd5d4..a5b8e7b80d17 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -164,8 +164,8 @@ SECTIONS
>          * The vectors and stubs are relocatable code, and the
>          * only thing that matters is their relative offsets
>          */
> -       __stubs_start = .;
>         .stubs : {
> +               __stubs_start = .;
>                 *(.stubs)
>         }
>         __stubs_end = .;


Yup, that fixed it!

bf353edc T _etext
bf353ee0 t __stubs_start
bf353ee0 T __stubs_start
bf353ee4 t vector_rst
bf353f00 t vector_irq

and my new print out:

     Stubs at c09ff000 :BF006F20 EF9F0000 EA000064 E320F000 etc...


Now that it is working on my XIP system, I will say that I'm also happy to see that extra junk in kallsyms.c and link-vmlinux.sh be removed. Those things also caused me some issues when I first started trying to get the XIP_KERNEL stuff back working.



Chris

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Ard Biesheuvel]

On 3 February 2016 at 15:15, Chris Brandt <Chris.Brandt@renesas.com> wrote:
> On 2 Feb 2016, Chris Brandt wrote
>> > And when a printed out the destination, I get:
>> >
>> >    Stubs at c09ff000 :00000000 BF006F20 EF9F0000 EA000064 etc...
>> >
>> > Notice the first entry is 0....that's not right...and we know it's using that
>> > first __stubs_start symbol.
>> >
>>
>> The first quantity after __stubs_start should be the address of vector_swi. Can
>>  you check if the second value coincides with that?
>
> Yes, it does.
>
> bf006f20 T vector_swi
>
> Which is why it booted once I modified the start address.
>
>
>> This is caused by the fact that __stubs_start is not aligned correctly on XIP.
>>
>> Could you try this, please?
>>
>> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S index 7160658fd5d4..a5b8e7b80d17 100644
>> --- a/arch/arm/kernel/vmlinux.lds.S
>> +++ b/arch/arm/kernel/vmlinux.lds.S
>> @@ -164,8 +164,8 @@ SECTIONS
>>          * The vectors and stubs are relocatable code, and the
>>          * only thing that matters is their relative offsets
>>          */
>> -       __stubs_start = .;
>>         .stubs : {
>> +               __stubs_start = .;
>>                 *(.stubs)
>>         }
>>         __stubs_end = .;
>
>
> Yup, that fixed it!
>
> bf353edc T _etext
> bf353ee0 t __stubs_start
> bf353ee0 T __stubs_start
> bf353ee4 t vector_rst
> bf353f00 t vector_irq
>
> and my new print out:
>
>      Stubs at c09ff000 :BF006F20 EF9F0000 EA000064 E320F000 etc...
>
>
> Now that it is working on my XIP system, I will say that I'm also happy to see that extra junk in kallsyms.c and link-vmlinux.sh be removed. Those things also caused me some issues when I first started trying to get the XIP_KERNEL stuff back working.
>

Glad to hear that it works now. Thanks a lot for testing.

-- 
Ard.

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Russell King - ARM Linux]

On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
> > bf353edc T __stubs_start
> 
> This is a global symbol
> 
> > bf353edc T _etext
> > bf353ee0 t __stubs_start
> 
> This is a local symbol

Stop this madness.  This gets you an immediate NAK on the patch set.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Ard Biesheuvel]

On 3 February 2016 at 21:01, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
>> > bf353edc T __stubs_start
>>
>> This is a global symbol
>>
>> > bf353edc T _etext
>> > bf353ee0 t __stubs_start
>>
>> This is a local symbol
>
> Stop this madness.  This gets you an immediate NAK on the patch set.
>

What madness? This does not change at all with my patches, these
duplicates already exist in the current code.

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Linus Walleij]

On Tue, Feb 2, 2016 at 2:19 PM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:

> a) CONFIG_HAVE_TCM creates a virtual region that is too far away for the
>    relative kallsyms code to reach it;

We have discussed the TCM before in context of SRAM and other
embedded on-chip RAMs.

There was some consensus that the statically allocated area for TCM is
not really scaleable, especially not for multiplatform kernels, which will
try to compile the sum total of all platforms' code tagged for TCM into this
memory which is bound to overflow if people start to take advantage
of it. It would be better to have just the machine-relevant code loaded
into TCM at boot. People have also shown interest in deploying
SRAM/TCM applications from userspace (for hard processing
kernels etc).

The best would be to advance that work and thus get rid of the
static TCM linkage I think?

Yours,
Linus Walleij

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Nicolas Pitre]

On Wed, 3 Feb 2016, Ard Biesheuvel wrote:

> On 3 February 2016 at 21:01, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
> >> > bf353edc T __stubs_start
> >>
> >> This is a global symbol
> >>
> >> > bf353edc T _etext
> >> > bf353ee0 t __stubs_start
> >>
> >> This is a local symbol
> >
> > Stop this madness.  This gets you an immediate NAK on the patch set.
> >
> 
> What madness? This does not change at all with my patches, these
> duplicates already exist in the current code.

That doesn't make it any better, and was cause for issue as Chris 
demonstrated.  Can we get rid of that duplication please?


Nicolas

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Ard Biesheuvel]

On 3 February 2016 at 21:23, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Wed, 3 Feb 2016, Ard Biesheuvel wrote:
>
>> On 3 February 2016 at 21:01, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
>> >> > bf353edc T __stubs_start
>> >>
>> >> This is a global symbol
>> >>
>> >> > bf353edc T _etext
>> >> > bf353ee0 t __stubs_start
>> >>
>> >> This is a local symbol
>> >
>> > Stop this madness.  This gets you an immediate NAK on the patch set.
>> >
>>
>> What madness? This does not change at all with my patches, these
>> duplicates already exist in the current code.
>
> That doesn't make it any better, and was cause for issue as Chris
> demonstrated.  Can we get rid of that duplication please?
>

4/4 in my v2 removes the redundant symbols.

[PATCH 0/3] kallsyms: remove special handling for CONFIG_ARM

[Ard Biesheuvel]

On 3 February 2016 at 21:30, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 3 February 2016 at 21:23, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> On Wed, 3 Feb 2016, Ard Biesheuvel wrote:
>>
>>> On 3 February 2016 at 21:01, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk> wrote:
>>> > On Wed, Feb 03, 2016 at 02:41:29PM +0100, Ard Biesheuvel wrote:
>>> >> > bf353edc T __stubs_start
>>> >>
>>> >> This is a global symbol
>>> >>
>>> >> > bf353edc T _etext
>>> >> > bf353ee0 t __stubs_start
>>> >>
>>> >> This is a local symbol
>>> >
>>> > Stop this madness.  This gets you an immediate NAK on the patch set.
>>> >
>>>
>>> What madness? This does not change at all with my patches, these
>>> duplicates already exist in the current code.
>>
>> That doesn't make it any better, and was cause for issue as Chris
>> demonstrated.  Can we get rid of that duplication please?
>>
>
> 4/4 in my v2 removes the redundant symbols.

... actually, that only removes the redundant __stub_start, and the
redundant __vectors_start is already removed in patch #1. Patch #4
(v2) may be shot down for other reasons, in that case I can simply
move the removal of __stubs_start to patch #1 instead.

[PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA

[Russell King - ARM Linux]

On Wed, Feb 03, 2016 at 10:16:46AM +0100, Ard Biesheuvel wrote:
> There are 34 section headers, starting at offset 0x10a6e60:
> 
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
>   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
...
> Section Headers:
>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
>   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32

Sorry, but I'm going to re-iterate my objection, and I believe that
because you're looking at readelf's output, you're making assumptions
when interpreting its output.

These figures do not truely describe how the file is laid out.  The
tool to use for this is objdump -h.  Let's compare:

$ readelf -S vmlinux
Section Headers:
  [Nr] Name        Type         Addr     Off    Size   ES Flg Lk Inf Al
  [13] .notes      NOTE         c093afd0 93afd0 000024 00  AX  0   0  4
  [14] .vectors    PROGBITS     00000000 940000 000020 00  AX  0   0  4
  [15] .stubs      PROGBITS     00001000 941000 0002c0 00  AX  0   0 32
  [16] .init.text  PROGBITS     c093b2e0 94b2e0 04862c 00  AX  0   0 32

$ objdump -h vmlinux
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
 12 .notes        00000024  c093afd0  c093afd0  0093afd0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .vectors      00000020  00000000  c093b000  00940000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 14 .stubs        000002c0  00001000  c093b020  00941000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 15 .init.text    0004862c  c093b2e0  c093b2e0  0094b2e0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

Note that objdump -h has one additional piece of information here: the
LMA - load memory address.  This tells us where the file contents
(offset into the ELF file at "File off") are to be loaded into memory,
as opposed to the VMA which describes where (at run time) the object is
to be found.

With this new information, we can see that .vectors is loaded to
0xc093b000, and occupies only 32 bytes in the binary memory image, even
though it occupies 4k in the ELF file.)  .stubs is loaded at 0xc093b020,
and occupies 0x2c0 bytes.  Furthermore, we can see .init.text is located
at 0xc093b2e0.

So, there is no memory wastage here - .vectors, .stubs and the init text
are all packed tightly together.  That's something which the readelf -S
output doesn't show us.

Please, replace the readelf -S output with objdump -h output so that we
can see what's /really/ going on here.

In any case, I still don't like your patch.  At least having these at 0
and 0x1000 means that (for some CPUs) they are located at the real VMA
address that they may appear at, though for modern CPUs, locating them
at 0xffff0000 and 0xffff1000 VMA would be more reasonable.  This has the
advantage that (jtag) debuggers are able to correctly parse the vmlinux
file and insert breakpoints into the vectors.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA

[Russell King - ARM Linux]

On Mon, Feb 08, 2016 at 04:39:35PM +0000, Russell King - ARM Linux wrote:
> On Wed, Feb 03, 2016 at 10:16:46AM +0100, Ard Biesheuvel wrote:
> > There are 34 section headers, starting at offset 0x10a6e60:
> > 
> > Section Headers:
> >   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> >   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
> >   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
> >   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
> >   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
> ...
> > Section Headers:
> >   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
> >   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
> >   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
> >   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
> >   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
> 
> Sorry, but I'm going to re-iterate my objection, and I believe that
> because you're looking at readelf's output, you're making assumptions
> when interpreting its output.
> 
> These figures do not truely describe how the file is laid out.  The
> tool to use for this is objdump -h.  Let's compare:
> 
> $ readelf -S vmlinux
> Section Headers:
>   [Nr] Name        Type         Addr     Off    Size   ES Flg Lk Inf Al
>   [13] .notes      NOTE         c093afd0 93afd0 000024 00  AX  0   0  4
>   [14] .vectors    PROGBITS     00000000 940000 000020 00  AX  0   0  4
>   [15] .stubs      PROGBITS     00001000 941000 0002c0 00  AX  0   0 32
>   [16] .init.text  PROGBITS     c093b2e0 94b2e0 04862c 00  AX  0   0 32
> 
> $ objdump -h vmlinux
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  12 .notes        00000024  c093afd0  c093afd0  0093afd0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  13 .vectors      00000020  00000000  c093b000  00940000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  14 .stubs        000002c0  00001000  c093b020  00941000  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  15 .init.text    0004862c  c093b2e0  c093b2e0  0094b2e0  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
> 
> Note that objdump -h has one additional piece of information here: the
> LMA - load memory address.  This tells us where the file contents
> (offset into the ELF file at "File off") are to be loaded into memory,
> as opposed to the VMA which describes where (at run time) the object is
> to be found.
> 
> With this new information, we can see that .vectors is loaded to
> 0xc093b000, and occupies only 32 bytes in the binary memory image, even
> though it occupies 4k in the ELF file.)  .stubs is loaded at 0xc093b020,
> and occupies 0x2c0 bytes.  Furthermore, we can see .init.text is located
> at 0xc093b2e0.
> 
> So, there is no memory wastage here - .vectors, .stubs and the init text
> are all packed tightly together.  That's something which the readelf -S
> output doesn't show us.
> 
> Please, replace the readelf -S output with objdump -h output so that we
> can see what's /really/ going on here.
> 
> In any case, I still don't like your patch.  At least having these at 0
> and 0x1000 means that (for some CPUs) they are located at the real VMA
> address that they may appear at, though for modern CPUs, locating them
> at 0xffff0000 and 0xffff1000 VMA would be more reasonable.  This has the
> advantage that (jtag) debuggers are able to correctly parse the vmlinux
> file and insert breakpoints into the vectors.

Another down-side to your patch is that you're placing the VMA of
.vectors 4096 bytes below .stubs - but we can have other symbols in
that VMA space.  That means you're creating the very real possibility
of confusing output we have real data at the location where you're
placing .vectors.

So no, I _really_ don't like this.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/3] ARM: move .vectors and .stubs sections back into the kernel VMA

[Ard Biesheuvel]

On 8 February 2016 at 17:39, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Feb 03, 2016 at 10:16:46AM +0100, Ard Biesheuvel wrote:
>> There are 34 section headers, starting at offset 0x10a6e60:
>>
>> Section Headers:
>>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>>   [16] .vectors          PROGBITS        00000000 a40000 000020 00  AX  0   0  2
>>   [17] .stubs            PROGBITS        00001000 a41000 0002c0 00  AX  0   0 32
>>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
> ...
>> Section Headers:
>>   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
>>   [15] .notes            NOTE            c0c34020 a34020 000024 00  AX  0   0  4
>>   [16] .stubs            PROGBITS        c0c35000 a35000 0002c0 00  AX  0   0 32
>>   [17] .vectors          PROGBITS        c0c34000 a44000 000020 00  AX  0   0  2
>>   [18] .init.text        PROGBITS        c0c352e0 a452e0 06b1b8 00  AX  0   0 32
>
> Sorry, but I'm going to re-iterate my objection, and I believe that
> because you're looking at readelf's output, you're making assumptions
> when interpreting its output.
>
> These figures do not truely describe how the file is laid out.  The
> tool to use for this is objdump -h.  Let's compare:
>
> $ readelf -S vmlinux
> Section Headers:
>   [Nr] Name        Type         Addr     Off    Size   ES Flg Lk Inf Al
>   [13] .notes      NOTE         c093afd0 93afd0 000024 00  AX  0   0  4
>   [14] .vectors    PROGBITS     00000000 940000 000020 00  AX  0   0  4
>   [15] .stubs      PROGBITS     00001000 941000 0002c0 00  AX  0   0 32
>   [16] .init.text  PROGBITS     c093b2e0 94b2e0 04862c 00  AX  0   0 32
>
> $ objdump -h vmlinux
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  12 .notes        00000024  c093afd0  c093afd0  0093afd0  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  13 .vectors      00000020  00000000  c093b000  00940000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  14 .stubs        000002c0  00001000  c093b020  00941000  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>  15 .init.text    0004862c  c093b2e0  c093b2e0  0094b2e0  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>
> Note that objdump -h has one additional piece of information here: the
> LMA - load memory address.  This tells us where the file contents
> (offset into the ELF file at "File off") are to be loaded into memory,
> as opposed to the VMA which describes where (at run time) the object is
> to be found.
>
> With this new information, we can see that .vectors is loaded to
> 0xc093b000, and occupies only 32 bytes in the binary memory image, even
> though it occupies 4k in the ELF file.)  .stubs is loaded at 0xc093b020,
> and occupies 0x2c0 bytes.  Furthermore, we can see .init.text is located
> at 0xc093b2e0.
>
> So, there is no memory wastage here - .vectors, .stubs and the init text
> are all packed tightly together.  That's something which the readelf -S
> output doesn't show us.
>
> Please, replace the readelf -S output with objdump -h output so that we
> can see what's /really/ going on here.
>

OK, fair enough.

Before:

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
 14 .notes        00000024  c0c90030  c0c90030  00a90030  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 15 .vectors      00000020  00000000  c0c91000  00aa0000  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 16 .stubs        000002c0  00001000  c0c91020  00aa1000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 17 .init.text    0006b250  c0c912e0  c0c912e0  00aa12e0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

and after

 14 .notes        00000024  c0c90030  c0c90030  00a90030  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 15 .stubs        000002c0  c0c91000  c0c91000  00a91000  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 16 .vectors      00000020  c0c90000  c0c912c0  00aa0000  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
 17 .init.text    0006b250  c0c912e0  c0c912e0  00aa12e0  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE

So, apart from the fact that .vectors and .stubs are reordered,
nothing changes, and the LMA footprint is identical.

> In any case, I still don't like your patch.  At least having these at 0
> and 0x1000 means that (for some CPUs) they are located at the real VMA
> address that they may appear at, though for modern CPUs, locating them
> at 0xffff0000 and 0xffff1000 VMA would be more reasonable.  This has the
> advantage that (jtag) debuggers are able to correctly parse the vmlinux
> file and insert breakpoints into the vectors.
>

0xffff0000 and 0xffff1000 work for me. I am trying to get rid of this
dodgy workaround in scripts/link-vmlinux.sh(85):

if [ -n "${CONFIG_ARM}" ] && [ -z "${CONFIG_XIP_KERNEL}" ] && [ -n
"${CONFIG_PAGE_OFFSET}" ]; then
    kallsymopt="${kallsymopt} --page-offset=$CONFIG_PAGE_OFFSET"
fi

which is there because perf does not like seeing the zero based kernel
symbol addresses, and only fixes the XIP_KERNEL=n case anyway.

Alternatively, this issue can be solved by making all stubs symbols
strictly local (or absolute), i.e., something like below. Would that
be preferable to you? It also fixes the perf issue for both
XIP_KERNEL=y and =n, but keeps .vectors and .stubs where they are.

-- 
Ard.


---------8<------------
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 788e40c1254f..c5c50c70c080 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -1027,7 +1027,7 @@ __kuser_helper_end:
  .macro vector_stub, name, mode, correction=0
  .align 5

-vector_\name:
+.Lvector_\name:
  .if \correction
  sub lr, lr, #\correction
  .endif
@@ -1056,7 +1056,7 @@ vector_\name:
  mov r0, sp
  ARM( ldr lr, [pc, lr, lsl #2] )
  movs pc, lr @ branch to handler in SVC mode
-ENDPROC(vector_\name)
+ENDPROC(.Lvector_\name)

  .align 2
  @ handler addresses follow this label
@@ -1064,14 +1064,15 @@ ENDPROC(vector_\name)
  .endm

  .section .stubs, "ax", %progbits
+.Lstubs_start:
  @ This must be the first word
  .word vector_swi

-vector_rst:
+.Lvector_rst:
  ARM( swi SYS_ERROR0 )
  THUMB( svc #0 )
  THUMB( nop )
- b vector_und
+ b .Lvector_und

 /*
  * Interrupt dispatcher
@@ -1173,8 +1174,8 @@ vector_rst:
  * (they're not supposed to happen, and won't happen in 32-bit data mode).
  */

-vector_addrexcptn:
- b vector_addrexcptn
+.Lvector_addrexcptn:
+ b .Lvector_addrexcptn

 /*=============================================================================
  * FIQ "NMI" handler
@@ -1202,18 +1203,18 @@ vector_addrexcptn:
  .long __fiq_svc @  f

  .globl vector_fiq_offset
- .equ vector_fiq_offset, vector_fiq
+ .equ vector_fiq_offset, .Lvector_fiq - .Lstubs_start + 0x1000

  .section .vectors, "ax", %progbits
 .L__vectors_start:
- W(b) vector_rst
- W(b) vector_und
+ W(b) .Lvector_rst
+ W(b) .Lvector_und
  W(ldr) pc, .L__vectors_start + 0x1000
- W(b) vector_pabt
- W(b) vector_dabt
- W(b) vector_addrexcptn
- W(b) vector_irq
- W(b) vector_fiq
+ W(b) .Lvector_pabt
+ W(b) .Lvector_dabt
+ W(b) .Lvector_addrexcptn
+ W(b) .Lvector_irq
+ W(b) .Lvector_fiq

  .data