This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: putting a variable in an own section
Torsten Mohr <tmohr at s dot netic dot de> writes:
> > http://sourceware.org/binutils/docs-2.12/ld.info/Output-Section-LMA.html#Ou
> >tput%20Section%20LMA
>
> thanks for that hint. That's exactly what i was
> searching for, but i have some problems with it.
>
> What's bothering me here is that there is no
> additional section generated, but isn't that
> necessary to mark a memory region as "used"
> or "reserved for something"?
On most systems it is not. Since you are generating S-records, what
you would expect to see in the reserved memory region? The S-records
will give you something to burn into PROM. You don't need anything to
put into RAM. Just initialize it at runtime.
> I'm testing this on v850-unknown-elf and i have
> for V850/SF1:
>
> .text : { *(.text) _etext = . ; } >rom
> .rodata : { *(.rodata) } >rom
> .data : AT(ADDR(.rodata)) { *(.data) } >ram
>
>
> But this leads to an error in the line with ".data":
> v850-unknown-elf-ld: ADDR forward reference of section .rodata
> What's wrong here?
Not sure, really. It might be a bug. On the other hand, the script
doesn't really make sense, because you're trying to load both .rodata
and .data at the same LMA.
> Now i've tried the following, basicall i put everything that
> goes in .data into .rodata and set the size of .data
> to the size of .rodata:
>
> .text : { *(.text) _etext = . ; } >rom
> .rodata : { *(.data) } >rom
> .data : { . += SIZEOF(.rodata); } >ram
I don't see any need to create the .data section at all.
> Do you see disadvantages of this approach?
I don't see a reason for it.
> .data doesn't go into S-Record, .rodata goes into S-Record. Is this
> because *(.data) is now in .rodata and .data is just a "fill"?
Yes. The .data output section has no contents, so there is nothing to
put in the S-records. What would you expect to see there?
Ian