Skip to contentSkip to conversation

s390: .align 4096 statements in head.S

PATCH In review Martin Schwidefsky 2 participants 5 messages Jul 18, 2006 s390

lore
Share & tools
lore
#0 lore raw

PATCH 5/6 s390: .align 4096 statements in head.S

From: Heiko Carstens <[email protected]>

[S390] .align 4096 statements in head.S

SLES9 binutils don't like .align 4096 statements in head.S. Work around this by using .org statements.

---

 arch/s390/kernel/head31.S |    4 ++--
 arch/s390/kernel/head64.S |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)
arch/s390/kernel/head31.S +2 -2
diff -urpN linux-2.6/arch/s390/kernel/head31.S linux-2.6-patched/arch/s390/kernel/head31.S
@@ -273,7 +273,7 @@ startup_continue:
 .Lbss_end:  .long _end
 .Lparmaddr: .long PARMAREA
 .Lsccbaddr: .long .Lsccb
-	.align	4096
+	.org	0x12000
 .Lsccb:
 	.hword	0x1000			# length, one page
 	.byte	0x00,0x00,0x00
@@ -290,7 +290,7 @@ startup_continue:
 .Lscpincr2:
 	.quad	0x00
 	.fill	3984,1,0
-	.align	4096
+	.org	0x13000
 
 #ifdef CONFIG_SHARED_KERNEL
 	.org	0x100000
arch/s390/kernel/head64.S +2 -2
diff -urpN linux-2.6/arch/s390/kernel/head64.S linux-2.6-patched/arch/s390/kernel/head64.S
@@ -268,7 +268,7 @@ startup_continue:
 .Lparmaddr:
 	.quad	PARMAREA
 
-	.align 4096
+	.org	0x12000
 .Lsccb:
 	.hword 0x1000			# length, one page
 	.byte 0x00,0x00,0x00
@@ -285,7 +285,7 @@ startup_continue:
 .Lscpincr2:
 	.quad 0x00
 	.fill 3984,1,0
-	.align 4096
+	.org	0x13000
 
 #ifdef CONFIG_SHARED_KERNEL
 	.org   0x100000
#1 lore raw
Quoted 55 lines · Martin Schwidefsky

From: Heiko Carstens <[email protected]>

[S390] .align 4096 statements in head.S

SLES9 binutils don't like .align 4096 statements in head.S. Work around this by using .org statements.

---

arch/s390/kernel/head31.S |    4 ++--
arch/s390/kernel/head64.S |    4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff -urpN linux-2.6/arch/s390/kernel/head31.S linux-2.6-patched/arch/s390/kernel/head31.S

arch/s390/kernel/head31.S +0 -0
@@ -273,7 +273,7 @@ startup_continue:

.Lbss_end: .long _end
.Lparmaddr: .long PARMAREA
.Lsccbaddr: .long .Lsccb

arch/s390/kernel/head31.S +1 -1
-	.align	4096
+	.org	0x12000

.Lsccb:

	.hword	0x1000			# length, one page
	.byte	0x00,0x00,0x00
arch/s390/kernel/head31.S +0 -0
@@ -290,7 +290,7 @@ startup_continue:

.Lscpincr2:

	.quad	0x00
	.fill	3984,1,0
arch/s390/kernel/head31.S +1 -1
-	.align	4096
+	.org	0x13000
#ifdef CONFIG_SHARED_KERNEL
	.org	0x100000

diff -urpN linux-2.6/arch/s390/kernel/head64.S linux-2.6-patched/arch/s390/kernel/head64.S

arch/s390/kernel/head64.S +0 -0
@@ -268,7 +268,7 @@ startup_continue:

.Lparmaddr:
.quad PARMAREA

arch/s390/kernel/head64.S +1 -1
-	.align 4096
+	.org	0x12000

.Lsccb:

	.hword 0x1000			# length, one page
	.byte 0x00,0x00,0x00
arch/s390/kernel/head64.S +0 -0
@@ -285,7 +285,7 @@ startup_continue:

.Lscpincr2:

	.quad 0x00
	.fill 3984,1,0
arch/s390/kernel/head64.S +1 -1
-	.align 4096
+	.org	0x13000
Quoted 3 lines
#ifdef CONFIG_SHARED_KERNEL
	.org   0x100000

-

Hardcoading like that can cause hard to find errors. It looks like you wrote something in 'C' and tried to use its assembly code. You should know that you don't need ".fill" if you have correctly allocated data.

The following will align objects on a 0x1000 boundary:

.section .data
foo: .word 0
.org (. + 0x1000) & -0x1000
bar: .word 0
.org (. + 0x1000) & -0x1000
xxx: .word 0
.org (. + 0x1000) & -0x1000
yyy: .word 0
.end

The 'gas' assembler is very powerful and even allows macros:

.macro ALIGN val
.org (. + \val) & -\val
.endm

.section .data
foo: .word 0
ALIGN 0x1000
bar: .word 0
ALIGN 0x1000
xxx: .word 0
ALIGN 0x1000
yyy: .word 0
ALIGN 0x1000
qqq: .word 0
.end

This generates:
Disassembly of section .data:

00000000 <foo>:
...
00001000 <bar>:
...
00002000 <xxx>:
...
00003000 <yyy>:
...
00004000 <qqq>:
...

Note the alignment.

You might want to use this kind of construction because it will eliminate alignment errors. If you add something that's out-of-range 'gas' will generate an error (like attempt of a negative origin).

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.63 BogoMips). New book: http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

#2 lore raw
Quoted 5 lines · linux-os (Dick Johnson)

Hardcoading like that can cause hard to find errors. It looks like you wrote something in 'C' and tried to use its assembly code. You should know that you don't need ".fill" if you have correctly allocated
data.

Huh ?!? We are talking about head.S here. That is pure assembler, no C anywhere. It is the startup code of the kernel, and we do want to control where things end up.

Signature · 8 lines
blue skies,
  Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

"Reality continues to ruin my life." - Calvin.
#3 lore raw
Quoted 11 lines · Martin Schwidefsky
Quoted 5 lines · linux-os (Dick Johnson)

Hardcoading like that can cause hard to find errors. It looks like you wrote something in 'C' and tried to use its assembly code. You should know that you don't need ".fill" if you have correctly allocated
data.

Huh ?!? We are talking about head.S here. That is pure assembler, no C anywhere. It is the startup code of the kernel, and we do want to control where things end up.

Quoted 7 lines

--
blue skies,
Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

Yes, I know exactly what I am saying and I mentioned the reference to 'C' because the ".Labels" start with ".L" as 'C' does it. Humans generally use human-readable names.

If you BOTHERED to read the rest of the email, I instructed one how to use the assembler 'gas' so I certainly know that it is not 'C'. Thank you.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.24 on an i686 machine (5592.63 BogoMips). New book: http://www.AbominableFirebug.com/
_


****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

#4 lore raw
Quoted 5 lines · linux-os (Dick Johnson)
Quoted 2 lines
Quoted 2 lines

It looks like
you wrote something in 'C' and tried to use its assembly code.

Yes, I know exactly what I am saying and I mentioned the reference to 'C' because the ".Labels" start with ".L" as 'C' does it. Humans generally use human-readable names.

You postulated that we have converted some C code and tried to use the resulting assembly code. We did not. Do not make assumptions.

Quoted 3 lines

If you BOTHERED to read the rest of the email, I instructed one how to use the assembler 'gas' so I certainly know that it is not 'C'. Thank you.

Thank you very much for your kind instruction how to use the assembler. The .fill statements are there for the definition of the SCCB that finds out about the memory size of the machine. An SCCB has a peculiar format, to make it independent of the location the .fill statements do make sense, even if they fill up with zeroes.

Signature · 8 lines
blue skies,
  Martin.

Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH

"Reality continues to ruin my life." - Calvin.