2019-11-25 16:55:37 +08:00
|
|
|
#name: non-contiguous-arm5
|
|
|
|
|
#source: non-contiguous-arm.s
|
2023-01-11 23:34:04 +08:00
|
|
|
#ld: --enable-non-contiguous-regions -T non-contiguous-arm5.ld -z max-page-size=0x10000
|
2019-11-25 16:55:37 +08:00
|
|
|
#objdump: -rdth
|
|
|
|
|
#xfail: [is_generic]
|
|
|
|
|
|
|
|
|
|
.*: file format elf32-(little|big)arm.*
|
|
|
|
|
|
|
|
|
|
Sections:
|
|
|
|
|
Idx Name Size VMA LMA File off Algn
|
|
|
|
|
0 \.raml 0000000c 1fff0000 1fff0000 00010000 2\*\*2
|
|
|
|
|
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
|
|
|
|
1 \.ramu 00000014 20000000 1fff000c 00020000 2\*\*2
|
|
|
|
|
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
|
|
|
|
2 \.ramz 00000050 20040000 20000014 00030000 2\*\*2
|
|
|
|
|
CONTENTS, ALLOC, LOAD, READONLY, CODE
|
|
|
|
|
3 .ARM.attributes 00000012 00000000 00000000 .* 2\*\*0
|
|
|
|
|
CONTENTS, READONLY
|
|
|
|
|
SYMBOL TABLE:
|
|
|
|
|
1fff0000 l d .raml 00000000 .raml
|
|
|
|
|
20000000 l d .ramu 00000000 .ramu
|
|
|
|
|
20040000 l d .ramz 00000000 .ramz
|
|
|
|
|
00000000 l d .ARM.attributes 00000000 .ARM.attributes
|
2021-01-04 14:43:51 +08:00
|
|
|
00000000 l df \*ABS\* 00000000 .*non-contiguous-arm.o
|
2019-11-25 16:55:37 +08:00
|
|
|
1fff000c g .raml 00000000 _raml_end
|
|
|
|
|
20000000 g .ramu 00000000 _ramu_start
|
|
|
|
|
20000000 g F .ramu 00000000 code2
|
|
|
|
|
20040000 g .ramz 00000000 _ramz_start
|
|
|
|
|
1fff0000 g .raml 00000000 _raml_start
|
|
|
|
|
2000000c g F .ramu 00000000 code3
|
|
|
|
|
1fff0000 g F .raml 00000000 code1
|
|
|
|
|
20040050 g .ramz 00000000 _ramz_end
|
|
|
|
|
20040000 g F .ramz 00000000 code4
|
|
|
|
|
20000014 g .ramu 00000000 _ramu_end
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Disassembly of section .raml:
|
|
|
|
|
|
|
|
|
|
1fff0000 \<code1\>:
|
opcodes/arm: use '@' consistently for the comment character
Looking at the ARM disassembler output, every comment seems to start
with a ';' character, so I assumed this was the correct character to
start an assembler comment.
I then spotted a couple of places where there was no ';', but instead,
just a '@' character. I thought that this was a case of a missing
';', and proposed a patch to add the missing ';' characters.
Turns out I was wrong, '@' is actually the ARM assembler comment
character, while ';' is the statement separator. Thus this:
nop ;@ comment
is two statements, the first is the 'nop' instruction, while the
second contains no instructions, just the '@ comment' comment text.
This:
nop @ comment
is a single 'nop' instruction followed by a comment. And finally,
this:
nop ; comment
is two statements, the first contains the 'nop' instruction, while the
second contains the instruction 'comment', which obviously isn't
actually an instruction at all.
Why this matters is that, in the next commit, I would like to add
libopcodes syntax styling support for ARM.
The question then is how should the disassembler style the three cases
above?
As '@' is the actual comment start character then clearly the '@' and
anything after it can be styled as a comment. But what about ';' in
the second example? Style as text? Style as a comment?
And the third example is even harder, what about the 'comment' text?
Style as an instruction mnemonic? Style as text? Style as a comment?
I think the only sensible answer is to move the disassembler to use
'@' consistently as its comment character, and remove all the uses of
';'.
Then, in the next commit, it's obvious what to do.
There's obviously a *lot* of tests that get updated by this commit,
the only actual code changes are in opcodes/arm-dis.c.
2022-09-03 01:15:30 +08:00
|
|
|
1fff0000: e1a00000 nop @ \(mov r0, r0\)
|
|
|
|
|
1fff0004: e1a00000 nop @ \(mov r0, r0\)
|
2019-11-25 16:55:37 +08:00
|
|
|
1fff0008: eb003ffc bl 20000000 \<code2\>
|
|
|
|
|
|
|
|
|
|
Disassembly of section .ramu:
|
|
|
|
|
|
|
|
|
|
20000000 \<code2\>:
|
opcodes/arm: use '@' consistently for the comment character
Looking at the ARM disassembler output, every comment seems to start
with a ';' character, so I assumed this was the correct character to
start an assembler comment.
I then spotted a couple of places where there was no ';', but instead,
just a '@' character. I thought that this was a case of a missing
';', and proposed a patch to add the missing ';' characters.
Turns out I was wrong, '@' is actually the ARM assembler comment
character, while ';' is the statement separator. Thus this:
nop ;@ comment
is two statements, the first is the 'nop' instruction, while the
second contains no instructions, just the '@ comment' comment text.
This:
nop @ comment
is a single 'nop' instruction followed by a comment. And finally,
this:
nop ; comment
is two statements, the first contains the 'nop' instruction, while the
second contains the instruction 'comment', which obviously isn't
actually an instruction at all.
Why this matters is that, in the next commit, I would like to add
libopcodes syntax styling support for ARM.
The question then is how should the disassembler style the three cases
above?
As '@' is the actual comment start character then clearly the '@' and
anything after it can be styled as a comment. But what about ';' in
the second example? Style as text? Style as a comment?
And the third example is even harder, what about the 'comment' text?
Style as an instruction mnemonic? Style as text? Style as a comment?
I think the only sensible answer is to move the disassembler to use
'@' consistently as its comment character, and remove all the uses of
';'.
Then, in the next commit, it's obvious what to do.
There's obviously a *lot* of tests that get updated by this commit,
the only actual code changes are in opcodes/arm-dis.c.
2022-09-03 01:15:30 +08:00
|
|
|
20000000: e1a00000 nop @ \(mov r0, r0\)
|
|
|
|
|
20000004: e1a00000 nop @ \(mov r0, r0\)
|
2019-11-25 16:55:37 +08:00
|
|
|
20000008: ebffffff bl 2000000c \<code3\>
|
|
|
|
|
|
|
|
|
|
2000000c \<code3\>:
|
opcodes/arm: use '@' consistently for the comment character
Looking at the ARM disassembler output, every comment seems to start
with a ';' character, so I assumed this was the correct character to
start an assembler comment.
I then spotted a couple of places where there was no ';', but instead,
just a '@' character. I thought that this was a case of a missing
';', and proposed a patch to add the missing ';' characters.
Turns out I was wrong, '@' is actually the ARM assembler comment
character, while ';' is the statement separator. Thus this:
nop ;@ comment
is two statements, the first is the 'nop' instruction, while the
second contains no instructions, just the '@ comment' comment text.
This:
nop @ comment
is a single 'nop' instruction followed by a comment. And finally,
this:
nop ; comment
is two statements, the first contains the 'nop' instruction, while the
second contains the instruction 'comment', which obviously isn't
actually an instruction at all.
Why this matters is that, in the next commit, I would like to add
libopcodes syntax styling support for ARM.
The question then is how should the disassembler style the three cases
above?
As '@' is the actual comment start character then clearly the '@' and
anything after it can be styled as a comment. But what about ';' in
the second example? Style as text? Style as a comment?
And the third example is even harder, what about the 'comment' text?
Style as an instruction mnemonic? Style as text? Style as a comment?
I think the only sensible answer is to move the disassembler to use
'@' consistently as its comment character, and remove all the uses of
';'.
Then, in the next commit, it's obvious what to do.
There's obviously a *lot* of tests that get updated by this commit,
the only actual code changes are in opcodes/arm-dis.c.
2022-09-03 01:15:30 +08:00
|
|
|
2000000c: e1a00000 nop @ \(mov r0, r0\)
|
2019-11-25 16:55:37 +08:00
|
|
|
20000010: eb00fffa bl 20040000 \<code4\>
|
|
|
|
|
|
|
|
|
|
Disassembly of section .ramz:
|
|
|
|
|
|
|
|
|
|
20040000 \<code4\>:
|
|
|
|
|
20040000: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040004: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040008: e1a00000 .word 0xe1a00000
|
|
|
|
|
2004000c: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040010: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040014: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040018: e1a00000 .word 0xe1a00000
|
|
|
|
|
2004001c: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040020: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040024: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040028: e1a00000 .word 0xe1a00000
|
|
|
|
|
2004002c: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040030: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040034: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040038: e1a00000 .word 0xe1a00000
|
|
|
|
|
2004003c: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040040: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040044: e1a00000 .word 0xe1a00000
|
|
|
|
|
20040048: e1a00000 .word 0xe1a00000
|
|
|
|
|
2004004c: e1a00000 .word 0xe1a00000
|
