* Re: Strange LMA/VMA behavior with regions
[not found] ` <BANLkTinEBMoiGna1KJKn1KqtvNsHdHynoA@mail.gmail.com>
@ 2011-05-12 14:09 ` Anitha Boyapati
2011-05-12 23:34 ` Alan Modra
0 siblings, 1 reply; 17+ messages in thread
From: Anitha Boyapati @ 2011-05-12 14:09 UTC (permalink / raw)
To: binutils, amodra
> 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
I agree that ALIGN() overrides input section alignment. But if we set
address for VMA using ALIGN(), should it affect LMA too? I think it
should not.
To illustrate further, I'll use the initial output presented in the
previous post. Please refer to the row of section [ 1] .text_os.
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
Here the value of LMA ( 0x80000002) is not 8-aligned. The section
.text_os is described in linker script as:
.text_os ALIGN(8) :
{
*(.text .text.* )
...
Note that address of LMA is not set explicitly. In such a scenario it
is a little
counter-intuitive to see LMA not following input section's alignment
(2**3 in this case) although no ALIGN() or AT() have been used. Looks
like a bug to me. Please let me know the reason if otherwise.
-- Anitha
(I was not subscribed to ML, so the conversation was copied from
archives. Formatting issues might turn up. Please excuse)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2011-05-12 14:09 ` Strange LMA/VMA behavior with regions Anitha Boyapati
@ 2011-05-12 23:34 ` Alan Modra
2011-05-13 2:44 ` Anitha Boyapati
0 siblings, 1 reply; 17+ messages in thread
From: Alan Modra @ 2011-05-12 23:34 UTC (permalink / raw)
To: Anitha Boyapati; +Cc: binutils
On Thu, May 12, 2011 at 07:38:59PM +0530, Anitha Boyapati wrote:
> > 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
>
> I agree that ALIGN() overrides input section alignment. But if we set
> address for VMA using ALIGN(), should it affect LMA too? I think it
> should not.
That would be inconsistent. If you specify an address for an output
section it most certainly should affect both VMA and LMA. After all,
LMA is equal to VMA in the usual case. I see no reason whatsoever to
treat an address that happens to use ALIGN any differently from any
other address.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2011-05-12 23:34 ` Alan Modra
@ 2011-05-13 2:44 ` Anitha Boyapati
2011-05-13 3:41 ` Alan Modra
0 siblings, 1 reply; 17+ messages in thread
From: Anitha Boyapati @ 2011-05-13 2:44 UTC (permalink / raw)
To: Anitha Boyapati, binutils
On 13 May 2011 05:03, Alan Modra <amodra@gmail.com> wrote:
> On Thu, May 12, 2011 at 07:38:59PM +0530, Anitha Boyapati wrote:
>> > 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
>>
>> I agree that ALIGN() overrides input section alignment. But if we set
>> address for VMA using ALIGN(), should it affect LMA too? I think it
>> should not.
>
> That would be inconsistent.
OK. The reason why I raised this point is because of the inconsistency
observed in one of the cases. Either VMA should equal LMA or LMA
should follow input section's alignment. But none of this happens
(explained below)
> If you specify an address for an output
> section it most certainly should affect both VMA and LMA. After all,
> LMA is equal to VMA in the usual case. I see no reason whatsoever to
> treat an address that happens to use ALIGN any differently from any
> other address.
In such a case I would like to point out 2 issues which may or may
not be related to the patch:
Case 1
======
In the case where ALIGN() is set for VMA but not for LMA, we can
observe that LMA is not equal to VMA. Taking the initial example
again, VMA of .text_os is 0x80000008 while LMA is 0x80000002. LMA is
neither equal to VMA nor is following input section's alignment. This
is a bug.
.text_os ALIGN(8):
.text_os 00000008 80000008 80000002 00000408 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
Case 2
======
In the case where ALIGN() is set for LMA but not for VMA, the output
behavior is as you mentioned - LMA and VMA are both equal. This is
probably ok.
.text_os : ALIGN(8)
.text_os 00000008 80000008 80000008 00000408 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
Here both VMA and LMA are 0x80000008
There is an inconsistency in the output between case 1 and case 2.
Only one of these can be right. (And I am assuming case 2 is correct
and case 1 is buggy. Let me know otherwise).
Anitha
>
> --
> Alan Modra
> Australia Development Lab, IBM
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
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:02 ` Boyapati, Anitha
0 siblings, 2 replies; 17+ messages in thread
From: Alan Modra @ 2011-05-13 3:41 UTC (permalink / raw)
To: Anitha Boyapati; +Cc: binutils
On Fri, May 13, 2011 at 08:14:19AM +0530, Anitha Boyapati wrote:
> This is a bug.
No, it is not. Your script sets the VMA in two ways, an address on
the output section, *and* by specifying a region with '>'. The
address overrides the region, so that is what you get for VMA. You
are setting the LMA by specifying a region with 'AT>', so you get the
current address of the region for LMA.
If you want different behaviour you're going to have to spend time
writing a patch for ld, and then convince maintainers that your change
won't break other people's ld scripts.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
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:02 ` Boyapati, Anitha
1 sibling, 1 reply; 17+ messages in thread
From: Anitha Boyapati @ 2011-05-13 4:15 UTC (permalink / raw)
To: Anitha Boyapati, binutils
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
On 13 May 2011 09:10, Alan Modra <amodra@gmail.com> wrote:
> On Fri, May 13, 2011 at 08:14:19AM +0530, Anitha Boyapati wrote:
>> This is a bug.
>
> No, it is not. Your script sets the VMA in two ways, an address on
> the output section, *and* by specifying a region with '>'. The
> address overrides the region, so that is what you get for VMA. You
Agreed.
> are setting the LMA by specifying a region with 'AT>', so you get the
> current address of the region for LMA.
>
Oops. I have missed that. Point taken.
In the process of verifying further, I have changed the linker script
by removing 'AT>' , still same output is observed.
1 .text_os 00000008 80000008 80000002 00000408 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
I am not specifying any LMA in this case but still I get the current
location for the LMA (Is this also expected?)
( However, if I don't specify VMA using '>', both LMA and VMA are
equal. Please find custom linker script attached for your convenience.
)
Anitha
[-- Attachment #2: custom_ls.txt --]
[-- Type: text/plain, Size: 509 bytes --]
/* Default linker script, for normal executables */
OUTPUT_FORMAT("elf32-avr32", "elf32-avr32",
"elf32-avr32")
OUTPUT_ARCH(avr32:uc)
SEARCH_DIR("/proj/builds/AVR32_REL_3.2.0_build00/install/avr32/lib");
/* Do we need any of these for elf?
__DYNAMIC = 0; */
MEMORY
{
FLASH (rxai!w) : ORIGIN = 0x80000000, LENGTH = 512K
}
/*
PHDRS {
flash PT_LOAD;
}
*/
SECTIONS
{
.mysec1_os :
{
*(.mysec1)
} >FLASH AT>FLASH
.text_os ALIGN(8) :
{
*(.text .text.* )
} > FLASH
}
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Strange LMA/VMA behavior with regions
2011-05-13 3:41 ` Alan Modra
2011-05-13 4:15 ` Anitha Boyapati
@ 2011-05-13 5:02 ` Boyapati, Anitha
2011-05-13 5:42 ` Alan Modra
1 sibling, 1 reply; 17+ messages in thread
From: Boyapati, Anitha @ 2011-05-13 5:02 UTC (permalink / raw)
To: Alan Modra, binutils
>On Fri, May 13, 2011 at 08:14:19AM +0530, Anitha Boyapati wrote:
>> This is a bug.
>
>No, it is not. Your script sets the VMA in two ways, an address on
>the output section, *and* by specifying a region with '>'. The
>address overrides the region, so that is what you get for VMA. You
>are setting the LMA by specifying a region with 'AT>', so you get the
>current address of the region for LMA.
>
>If you want different behaviour you're going to have to spend time
>writing a patch for ld, and then convince maintainers that your change
>won't break other people's ld scripts.
>
I think the same logic given in para(1) is applicable to Case 2 discussed earlier. The relevant portion from linker script for Case 2 is:
.text_os : ALIGN(8) {
...
} >FLASH AT>FLASH
As I understand it, the address returned by ALIGN(8) has overridden both '>FLASH' and 'AT>FLASH'. While in case 1, ALIGN(8) has overridden only '>FLASH'. It is confusing to see different results.
Thanks for the conversations Alan.
Anitha
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2011-05-13 4:15 ` Anitha Boyapati
@ 2011-05-13 5:26 ` Alan Modra
2011-05-13 5:45 ` Boyapati, Anitha
0 siblings, 1 reply; 17+ messages in thread
From: Alan Modra @ 2011-05-13 5:26 UTC (permalink / raw)
To: Anitha Boyapati; +Cc: binutils
On Fri, May 13, 2011 at 09:44:43AM +0530, Anitha Boyapati wrote:
> In the process of verifying further, I have changed the linker script
> by removing 'AT>' , still same output is observed.
>
> 1 .text_os 00000008 80000008 80000002 00000408 2**3
> CONTENTS, ALLOC, LOAD, READONLY, CODE
>
> I am not specifying any LMA in this case but still I get the current
> location for the LMA (Is this also expected?)
Now this probably is a bug, introduced by
http://sourceware.org/ml/binutils/2009-04/msg00068.html
Fix as follows.
* ldlang.c (lang_leave_output_section_statement): Don't copy
previous lma_region if given address.
Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.367
diff -u -p -r1.367 ldlang.c
--- ld/ldlang.c 3 May 2011 14:56:14 -0000 1.367
+++ ld/ldlang.c 13 May 2011 05:23:40 -0000
@@ -6912,11 +6912,13 @@ lang_leave_output_section_statement (fil
current_section->load_base != NULL,
current_section->addr_tree != NULL);
- /* If this section has no load region or base, but has the same
+ /* If this section has no load region or base, but uses the same
region as the previous section, then propagate the previous
section's load region. */
- if (!current_section->lma_region && !current_section->load_base
+ if (current_section->lma_region == NULL
+ && current_section->load_base == NULL
+ && current_section->addr_tree == NULL
&& current_section->region == current_section->prev->region)
current_section->lma_region = current_section->prev->lma_region;
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2011-05-13 5:02 ` Boyapati, Anitha
@ 2011-05-13 5:42 ` Alan Modra
0 siblings, 0 replies; 17+ messages in thread
From: Alan Modra @ 2011-05-13 5:42 UTC (permalink / raw)
To: Boyapati, Anitha; +Cc: binutils
On Fri, May 13, 2011 at 01:02:24PM +0800, Boyapati, Anitha wrote:
> I think the same logic given in para(1) is applicable to Case 2 discussed earlier. The relevant portion from linker script for Case 2 is:
>
> .text_os : ALIGN(8) {
> ...
> } >FLASH AT>FLASH
>
> As I understand it, the address returned by ALIGN(8) has overridden both '>FLASH' and 'AT>FLASH'.
In your case 2, ALIGN(8) is *not* an address.. It's actually an
alignment applied to the output section VMA and LMA.
> While in case 1, ALIGN(8) has overridden only '>FLASH'. It is confusing to see different results.
Yes, this is confusing, and the ld info doc doesn't cover everything.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Strange LMA/VMA behavior with regions
2011-05-13 5:26 ` Alan Modra
@ 2011-05-13 5:45 ` Boyapati, Anitha
0 siblings, 0 replies; 17+ messages in thread
From: Boyapati, Anitha @ 2011-05-13 5:45 UTC (permalink / raw)
To: Alan Modra, binutils
>
>On Fri, May 13, 2011 at 09:44:43AM +0530, Anitha Boyapati wrote:
>> In the process of verifying further, I have changed the linker script
>> by removing 'AT>' , still same output is observed.
>>
>> 1 .text_os 00000008 80000008 80000002 00000408 2**3
>> CONTENTS, ALLOC, LOAD, READONLY, CODE
>>
>> I am not specifying any LMA in this case but still I get the current
>> location for the LMA (Is this also expected?)
>
>Now this probably is a bug, introduced by
>http://sourceware.org/ml/binutils/2009-04/msg00068.html
>Fix as follows.
>
> * ldlang.c (lang_leave_output_section_statement): Don't copy
> previous lma_region if given address.
Thanks for the fix too. Will get back to you with the results (or maybe more questions) :-)
Anitha
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Strange LMA/VMA behavior with regions
2011-05-11 7:20 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
* 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
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
* 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-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-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-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
* 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
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 --
[not found] <BANLkTi=+O9YvCp42jT3k0fKiC4z0opvAdA@mail.gmail.com>
[not found] ` <BANLkTinEBMoiGna1KJKn1KqtvNsHdHynoA@mail.gmail.com>
2011-05-12 14:09 ` Strange LMA/VMA behavior with regions 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
2011-05-11 7:20 Abnikant Singh
2011-05-11 7:45 ` 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).