Re: Strange LMA/VMA behavior with regions

Re: Strange LMA/VMA behavior with regions

[Anitha Boyapati]

> 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)

Re: Strange LMA/VMA behavior with regions

[Alan Modra]

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

Re: Strange LMA/VMA behavior with regions

[Anitha Boyapati]

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
>

Re: Strange LMA/VMA behavior with regions

[Alan Modra]

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

Re: Strange LMA/VMA behavior with regions

[Anitha Boyapati]

[-- 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
}

RE: Strange LMA/VMA behavior with regions

[Boyapati, Anitha]

>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

Re: Strange LMA/VMA behavior with regions

[Alan Modra]

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

Re: Strange LMA/VMA behavior with regions

[Alan Modra]

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

RE: Strange LMA/VMA behavior with regions

[Boyapati, Anitha]

>
>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

Re: Strange LMA/VMA behavior with regions

[Alan Modra]

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

Re: Strange LMA/VMA behavior with regions

[Abnikant Singh]

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

Re: Strange LMA/VMA behavior with regions

[Sebastian Huber]

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.

Re: Strange LMA/VMA behavior with regions

[Alan Modra]

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

Re: Strange LMA/VMA behavior with regions

[Sebastian Huber]

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.

Re: Strange LMA/VMA behavior with regions

[Alan Modra]

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

Re: Strange LMA/VMA behavior with regions

[Sebastian Huber]

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.

Strange LMA/VMA behavior with regions

[Sebastian Huber]

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.