* Re: Strange LMA/VMA behavior with regions
@ 2011-05-11 7:20 Abnikant Singh
2011-05-11 7:45 ` Alan Modra
0 siblings, 1 reply; 17+ messages in thread
From: Abnikant Singh @ 2011-05-11 7:20 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
Hi Alan,
I have tested your patch for LMA/VMA alignment issue on AVR
toolchain.I am facing the following issue when using the ALIGN
dirctive to align
the VMA. I am linking the following program object files..[1 & 2]
1. asm.s
.section .mysec1, "ax"
nop
.text
.balign 8
.global _balignfunc
.type _balignfunc, @function
_balignfunc:
NOP
2. asm2.s
.section .mysec1, "ax"
.global _func
.type _func, @function
_func:
NOP
The following linker script I am using to link the above programs.
MEMORY
{
FLASH (rxai!w) : ORIGIN = 0x80000000, LENGTH = 512K
}
SECTIONS
{
.mysec1_os :
{
*(.mysec1)
} >FLASH AT>FLASH
.text_os ALIGN(8) :
{
*(.text .text.* )
} > FLASH AT>FLASH
}
The objdump -h shows the following output:
Sections:
Idx Name Size VMA LMA File off Algn
0 .mysec1_os 00000002 80000000 80000000 00000400 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .text_os 00000008 80000008 80000002 00000408 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
As we can notice the Algn filed shown is 2**3, LMA is not following
the section alignment [which is 80000002]. In asm.s
.balign is 8, which I think should be taken as the input section
alignment and in init_os it should set section alignment as 8.
However if I directly give output section alignment, LMA get the
required alignment i.e. if in the linker script I use
......
.......
.text_os ALIGN(8) : ALIGN(8)
{
*(.text .text.* )
} > FLASH AT>FLASH
}
I get the following output..
Sections:
Idx Name Size VMA LMA File off Algn
0 .mysec1_os 00000002 80000000 80000000 00000400 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .text_os 00000008 80000008 80000008 00000408 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
Please give the inputs...
Is this the expected behavior or am I missing something ?
Regards,
Abnikant
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2011-05-11 7:20 Strange LMA/VMA behavior with regions Abnikant Singh
@ 2011-05-11 7:45 ` Alan Modra
0 siblings, 0 replies; 17+ messages in thread
From: Alan Modra @ 2011-05-11 7:45 UTC (permalink / raw)
To: Abnikant Singh; +Cc: binutils
On Wed, May 11, 2011 at 12:50:31PM +0530, Abnikant Singh wrote:
> .text_os ALIGN(8) :
This says to set the address of the output section .text_os. When you
set the address, any input section alignment is ignored. This happens
for LMA too. The fact that your address uses the ALIGN keyword
doesn't mean anything, you are not setting alignment..
> .text_os ALIGN(8) : ALIGN(8)
as you do here.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <BANLkTi=+O9YvCp42jT3k0fKiC4z0opvAdA@mail.gmail.com>]
* Strange LMA/VMA behavior with regions
@ 2010-11-29 13:15 Sebastian Huber
2010-11-30 17:00 ` Sebastian Huber
0 siblings, 1 reply; 17+ messages in thread
From: Sebastian Huber @ 2010-11-29 13:15 UTC (permalink / raw)
To: Binutils
Hi,
I have to write a custom linker script to distribute various output sections to
various physical memory regions (for embedded devices). I have this linker
SECTIONS part:
.jcr : {
KEEP (*(.jcr))
} > REGION AT > REGION
.rodata : {
*(.rodata .rodata.* .gnu.linkonce.r.*)
} > REGION AT > REGION
The .rodata section has a section alignment of 8 (the alignment depends on the
application, it may be higher). Now suppose that the .jcr end is not 8 bytes
aligned. We may have this:
.jcr 0x00000000800198b0 0x4
*(.jcr)
.jcr 0x00000000800198b0 0x0 crtbegin.o
.jcr 0x00000000800198b0 0x4 crtend.o
.rodata 0x00000000800198b8 0x2ba8 load address 0x00000000800198b4
*(.rodata .rodata.* .gnu.linkonce.r.*)
This is pretty bad, since this introduces a 4 byte offset in the .rodata
section. If I use this SECTIONS part:
.jcr : {
KEEP (*(.jcr))
} > REGION AT > REGION
.rodata : ALIGN (8) {
*(.rodata .rodata.* .gnu.linkonce.r.*)
} > REGION AT > REGION
We get this:
.jcr 0x00000000800198b0 0x4
*(.jcr)
.jcr 0x00000000800198b0 0x0 crtbegin.o
.jcr 0x00000000800198b0 0x4 crtend.o
.rodata 0x00000000800198b8 0x2ba8
*(.rodata .rodata.* .gnu.linkonce.r.*)
Unfortunately the section alignment is unknown in advance, so .rodata : ALIGN
(ALIGNOF(.rodata)) { ... } is not possible. Please observe that LMA==VMA in
.jcr. Let OFFSET := LMA - VMA. I think that LD should not introduce an OFFSET
!= 0 due to alignment constraints if the load and runtime region are equal.
Have a nice day!
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2010-11-29 13:15 Sebastian Huber
@ 2010-11-30 17:00 ` Sebastian Huber
2010-12-01 13:13 ` Alan Modra
0 siblings, 1 reply; 17+ messages in thread
From: Sebastian Huber @ 2010-11-30 17:00 UTC (permalink / raw)
To: binutils
Hi,
I tried to figure out why LD produced this gap.
If I change the LD behavior like this
Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.348
diff -u -r1.348 ldlang.c
--- ld/ldlang.c 21 Nov 2010 20:36:24 -0000 1.348
+++ ld/ldlang.c 30 Nov 2010 14:46:50 -0000
@@ -4919,6 +4919,7 @@
{
bfd_vma savedot = newdot;
newdot = align_power (newdot, align);
+ os->region->current = newdot;
if (newdot != savedot
&& (config.warn_section_align
the problem disappears. The section begin alignment consumes now also space in
the run-time region. In case the run-time and load-time regions are equal this
will prevent the artificial offsets. Please note that the test case "TLS
-fno-pic -shared" in "ld/testsuite/ld-i386/i386.exp" fails now.
Readelf dump without patch:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .hash HASH 000000b4 0000b4 00003c 04 A 2 0 4
[ 2] .dynsym DYNSYM 000000f0 0000f0 0000a0 10 A 3 1 4
[ 3] .dynstr STRTAB 00000190 000190 000031 00 A 0 0 1
[ 4] .rel.dyn REL 000001c4 0001c4 0000a0 08 A 2 0 4
[ 5] .text PROGBITS 00001000 001000 0000f4 00 AX 0 0 4096
[ 6] .tbss NOBITS 000020f4 0010f4 000024 00 WAT 0 0 1
[ 7] .dynamic DYNAMIC 000020f4 0010f4 000080 08 WA 3 0 4
[ 8] .got PROGBITS 00002174 001174 000018 04 WA 0 0 4
[ 9] .got.plt PROGBITS 0000218c 00118c 00000c 04 WA 0 0 4
[10] .shstrtab STRTAB 00000000 001198 00005d 00 0 0 1
[11] .symtab SYMTAB 00000000 001400 0001e0 10 12 21 4
[12] .strtab STRTAB 00000000 0015e0 000074 00 0 0 1
Readelf dump with patch:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .hash HASH 000000b4 0000b4 00003c 04 A 2 0 4
[ 2] .dynsym DYNSYM 000000f0 0000f0 0000a0 10 A 3 1 4
[ 3] .dynstr STRTAB 00000190 000190 000031 00 A 0 0 1
[ 4] .rel.dyn REL 000001c4 0001c4 0000a0 08 A 2 0 4
[ 5] .text PROGBITS 00001000 001000 0000f4 00 AX 0 0 4096
[ 6] .tbss NOBITS 00002000 002000 000024 00 WAT 0 0 1
[ 7] .dynamic DYNAMIC 00002000 002000 000080 08 WA 3 0 4
[ 8] .got PROGBITS 00002080 002080 000018 04 WA 0 0 4
[ 9] .got.plt PROGBITS 00002098 002098 00000c 04 WA 0 0 4
[10] .shstrtab STRTAB 00000000 0020a4 00005d 00 0 0 1
[11] .symtab SYMTAB 00000000 00230c 0001e0 10 12 21 4
[12] .strtab STRTAB 00000000 0024ec 000074 00 0 0 1
Is this a problem? It would be nice if we can use this patch, because this
simplifies linker command files for embedded devices with a scattered memory
map considerable.
Have a nice day!
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2010-11-30 17:00 ` Sebastian Huber
@ 2010-12-01 13:13 ` Alan Modra
2010-12-01 15:03 ` Sebastian Huber
0 siblings, 1 reply; 17+ messages in thread
From: Alan Modra @ 2010-12-01 13:13 UTC (permalink / raw)
To: Sebastian Huber; +Cc: binutils
Please test this for me. I think it will cure the problem.
* ldlang.c (lang_size_sections_1): Align lma using same alignment
as for vma.
Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.348
diff -u -p -r1.348 ldlang.c
--- ld/ldlang.c 21 Nov 2010 20:36:24 -0000 1.348
+++ ld/ldlang.c 1 Dec 2010 12:24:41 -0000
@@ -4788,6 +4788,7 @@ lang_size_sections_1
bfd_vma newdot, after;
lang_output_section_statement_type *os;
lang_memory_region_type *r;
+ int section_alignment = 0;
os = &s->output_section_statement;
if (os->constraint == -1)
@@ -4857,8 +4858,6 @@ lang_size_sections_1
}
else
{
- int align;
-
if (os->addr_tree == NULL)
{
/* No address specified for this section, get one
@@ -4909,16 +4908,16 @@ lang_size_sections_1
}
newdot = os->region->current;
- align = os->bfd_section->alignment_power;
+ section_alignment = os->bfd_section->alignment_power;
}
else
- align = os->section_alignment;
+ section_alignment = os->section_alignment;
/* Align to what the section needs. */
- if (align > 0)
+ if (section_alignment > 0)
{
bfd_vma savedot = newdot;
- newdot = align_power (newdot, align);
+ newdot = align_power (newdot, section_alignment);
if (newdot != savedot
&& (config.warn_section_align
@@ -4974,8 +4973,8 @@ lang_size_sections_1
{
bfd_vma lma = os->lma_region->current;
- if (os->section_alignment != -1)
- lma = align_power (lma, os->section_alignment);
+ if (section_alignment > 0)
+ lma = align_power (lma, section_alignment);
os->bfd_section->lma = lma;
}
else if (r->last_os != NULL
@@ -5016,8 +5015,8 @@ lang_size_sections_1
else
lma = dot + last->lma - last->vma;
- if (os->section_alignment != -1)
- lma = align_power (lma, os->section_alignment);
+ if (section_alignment > 0)
+ lma = align_power (lma, section_alignment);
os->bfd_section->lma = lma;
}
}
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2010-12-01 13:13 ` Alan Modra
@ 2010-12-01 15:03 ` Sebastian Huber
2010-12-02 0:46 ` Alan Modra
0 siblings, 1 reply; 17+ messages in thread
From: Sebastian Huber @ 2010-12-01 15:03 UTC (permalink / raw)
To: binutils
Hello Alan,
thank you for your investigations. I tested it with my ARM tool chain and on
Linux. It cures indeed the problem. The patch has no impact on the test suite
results.
I am unsure what happens if
os->section_alignment > os->bfd_section->alignment_power.
In line 4977 we previously used os->section_alignment, but now this is
section_alignment. It may have the value from line 4911
(os->bfd_section->alignment_power)?
Have a nice day!
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2010-12-01 15:03 ` Sebastian Huber
@ 2010-12-02 0:46 ` Alan Modra
2010-12-02 8:03 ` Sebastian Huber
0 siblings, 1 reply; 17+ messages in thread
From: Alan Modra @ 2010-12-02 0:46 UTC (permalink / raw)
To: Sebastian Huber; +Cc: binutils
On Wed, Dec 01, 2010 at 04:03:34PM +0100, Sebastian Huber wrote:
> I am unsure what happens if
> os->section_alignment > os->bfd_section->alignment_power.
That shouldn't happen. os->bfd_section->alignment_power is set from
os->section_alignment in os_init, and can only increase thereafter.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2010-12-02 0:46 ` Alan Modra
@ 2010-12-02 8:03 ` Sebastian Huber
0 siblings, 0 replies; 17+ messages in thread
From: Sebastian Huber @ 2010-12-02 8:03 UTC (permalink / raw)
To: binutils
On 12/02/2010 01:46 AM, Alan Modra wrote:
> On Wed, Dec 01, 2010 at 04:03:34PM +0100, Sebastian Huber wrote:
>> I am unsure what happens if
>> os->section_alignment > os->bfd_section->alignment_power.
>
> That shouldn't happen. os->bfd_section->alignment_power is set from
> os->section_alignment in os_init, and can only increase thereafter.
>
Ok, it would be nice if you can commit your patch.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-05-13 5:45 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-11 7:20 Strange LMA/VMA behavior with regions Abnikant Singh
2011-05-11 7:45 ` Alan Modra
[not found] <BANLkTi=+O9YvCp42jT3k0fKiC4z0opvAdA@mail.gmail.com>
[not found] ` <BANLkTinEBMoiGna1KJKn1KqtvNsHdHynoA@mail.gmail.com>
2011-05-12 14:09 ` Anitha Boyapati
2011-05-12 23:34 ` Alan Modra
2011-05-13 2:44 ` Anitha Boyapati
2011-05-13 3:41 ` Alan Modra
2011-05-13 4:15 ` Anitha Boyapati
2011-05-13 5:26 ` Alan Modra
2011-05-13 5:45 ` Boyapati, Anitha
2011-05-13 5:02 ` Boyapati, Anitha
2011-05-13 5:42 ` Alan Modra
-- strict thread matches above, loose matches on Subject: below --
2010-11-29 13:15 Sebastian Huber
2010-11-30 17:00 ` Sebastian Huber
2010-12-01 13:13 ` Alan Modra
2010-12-01 15:03 ` Sebastian Huber
2010-12-02 0:46 ` Alan Modra
2010-12-02 8:03 ` Sebastian Huber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).