Hi Adrian,
On 22/02/23 10:46, John Paul Adrian Glaubitz wrote:
Hi Michael!
On Wed, 2023-02-22 at 10:09 +1300, Michael Schmitz wrote:
a1 is just before the end of your RAM chunk. If that's a longword
Actually it isn't that close - if I read the stack correctly, we're
comparing 0xc bytes from 0x0f7ffff4 which is to 0x0f7ffffff.
The post-increment of a5 to 0x0f800000 might cause a pre-fetch beyond
end of memory - how does that get handled?
access, you'd fall over the edge :) Can you disassemble the code snippet
(or memcmp()) so we can see what's happening?
Here you go:
00201d14 <memcmp>:
201d14: 48e7 301c moveml %d2-%d3/%a3-%a5,%sp@-
201d18: 226f 0018 moveal %sp@(24),%a1
201d1c: 266f 001c moveal %sp@(28),%a3
201d20: 206f 0020 moveal %sp@(32),%a0
201d24: 7003 moveq #3,%d0
201d26: b088 cmpl %a0,%d0
201d28: 650a bcss 201d34 <memcmp+0x20>
201d2a: 4281 clrl %d1
201d2c: b288 cmpl %a0,%d1
201d2e: 661e bnes 201d4e <memcmp+0x3a>
201d30: 4280 clrl %d0
201d32: 6030 bras 201d64 <memcmp+0x50>
201d34: 2a49 moveal %a1,%a5 <======= 0x0f7ffff4
201d36: 284b moveal %a3,%a4
201d38: 264c moveal %a4,%a3
201d3a: 224d moveal %a5,%a1
201d3c: bb8c cmpml %a4@+,%a5@+ <======= a5 will be 0x0f800000 after post-increment
201d3e: 66ea bnes 201d2a <memcmp+0x16>
201d40: 5988 subql #4,%a0
201d42: 7003 moveq #3,%d0
201d44: b088 cmpl %a0,%d0
201d46: 65f0 bcss 201d38 <memcmp+0x24>
201d48: 224d moveal %a5,%a1
201d4a: 264c moveal %a4,%a3
201d4c: 60dc bras 201d2a <memcmp+0x16>
201d4e: 4283 clrl %d3
201d50: 1631 1800 moveb %a1@(0,%d1:l),%d3
201d54: 4282 clrl %d2
201d56: 1433 1800 moveb %a3@(0,%d1:l),%d2
201d5a: 2003 movel %d3,%d0
201d5c: 9082 subl %d2,%d0
201d5e: 5281 addql #1,%d1
201d60: b483 cmpl %d3,%d2
201d62: 67c8 beqs 201d2c <memcmp+0x18>
201d64: 4cdf 380c moveml %sp@+,%d2-%d3/%a3-%a5
201d68: 4e75 rts
The kernel image is actually unstripped. Is there a config option for that?
I'm sure the compressed kernel image is stripped but includes the kernel
symbol table (see below). The symbol table is definitely good to have
(otherwise you'd have to figure what all the addresses on the stack mean
from a separate symbol table).
Do we want to keep symbols in a non-debug kernel?
Definitely ...
Cheers,
Michael
Output of objdump -h:
vmlinux-6.2.0-rc8-atari-fpuemu-atafbfix+: file format elf32-m68k
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0030169c 00001000 00001000 00001000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 __ex_table 00001ab0 003026a0 003026a0 003026a0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .rodata 000c81e8 00305000 00305000 00305000 2**4
CONTENTS, ALLOC, LOAD, DATA
3 __ksymtab 00009a14 003cd1e8 003cd1e8 003cd1e8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 __ksymtab_gpl 000057c0 003d6bfc 003d6bfc 003d6bfc 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 __ksymtab_strings 000166a3 003dc3bc 003dc3bc 003dc3bc 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 __param 000006cc 003f2a60 003f2a60 003f2a60 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 __modver 00000088 003f312c 003f312c 003f312c 2**1
CONTENTS, ALLOC, LOAD, DATA
8 .notes 00000054 003f31b4 003f31b4 003f31b4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .data 00051a20 003f4000 003f4000 003f4000 2**4
CONTENTS, ALLOC, LOAD, DATA
10 .bss 0002266c 00445a20 00445a20 00445a20 2**4
ALLOC
11 .init.text 00017be0 00469000 00469000 00447000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 .init.data 00004c1c 00480be0 00480be0 0045ebe0 2**2
CONTENTS, ALLOC, LOAD, DATA
13 .m68k_fixup 00000480 004857fc 004857fc 004637fc 2**0
CONTENTS, ALLOC, LOAD, DATA
14 .init_end 00000384 00485c7c 00485c7c 00463c7c 2**0
ALLOC
15 .comment 0000002d 00000000 00000000 00463c7c 2**0
CONTENTS, READONLY
I do recall recent changes to the mm code, but that was for NOMMU. I
wonder whether there was anything else that would introduce an implicit
assumption about memory starting at 0x0 ...
Sounds like a possible culprit.
Adrian
