Federico Spadini wrote:
> I'm relatively new to the whole linker scripting idea, but I'm trying to
> port some bootloader code on PXA271 (arm5 variant)...
>
> Would anyone be able to tell me where I can find a list of the default
> input/output sections and what they are typically used for?
> ...

Input sections generated by the C-compiler are basically: .text for
code, rodata for constants (read only), .data for static variables which
need to be initialized and .bss for zero-initialized variables.
Depending on your compiler-settings and target there may be additional
sections (glue functions, linkonce, separated sections for each
function, "common" and more). Traditional names for the output sections
are .text, .bss and .data but other names and additional sections can be
used depending on the target and used tools to process the
linker-output. It will be easier to help if you paste your linker-script
here and mark the "problematic" lines/sections.

Hi Martin,
Thanks for the reply, here's the linker script:
http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x/tos/platforms/intelmote2/tos.x?view=markup

I wanted to understand what the .linkonce was, .glue_7t, .gnu.warning,
.fini, .linkonce.d, .dynbss, .note.GNU-stack and the debugger sections!
I know its a lot, if you have a reference I might be able to peak at
that would be awesome.

Also, what generally goes shoved in the .edata section?

Sorry, linker scripts were foreign to me (and I'm still learning). They
always just worked until now :-)

Thanks a lot,
Federico

Martin Thomas wrote:
> Federico Spadini wrote:
>> I'm relatively new to the whole linker scripting idea, but I'm trying to
>> port some bootloader code on PXA271 (arm5 variant)...
>>
>> Would anyone be able to tell me where I can find a list of the default
>> input/output sections and what they are typically used for?
>> ...
>
> Input sections generated by the C-compiler are basically: .text for
> code, rodata for constants (read only), .data for static variables which
> need to be initialized and .bss for zero-initialized variables.
> Depending on your compiler-settings and target there may be additional
> sections (glue functions, linkonce, separated sections for each
> function, "common" and more). Traditional names for the output sections
> are .text, .bss and .data but other names and additional sections can be
> used depending on the target and used tools to process the
> linker-output. It will be easier to help if you paste your linker-script
> here and mark the "problematic" lines/sections.

Federico Spadini wrote:
> Hi Martin,
> Thanks for the reply, here's the linker script:
> 
http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x/tos/platforms/intelmote2/tos.x?view=markup
>
> I wanted to understand what the .linkonce was, .glue_7t, .gnu.warning,
> .fini, .linkonce.d, .dynbss, .note.GNU-stack and the debugger sections!
> I know its a lot, if you have a reference I might be able to peak at
> that would be awesome.

Well, I don't know the meaning of all those entries too. Usually I try
to take already available example linker-scripts for the target(-family)
and the default linker-script as templates and modify or reduce them to
my needs. The manual of the GNU-linker has some useful information. You
may also find information on them in the "gcc internals" documentation
available from gcc.gnu.org.

Just a few remarks:
- The compiler places interface-functions for needed for interworking in
.glue*
- As far as I know linkonce* tells the linker to link identical elements
only once
- The debugger sections can be copied from the default linker-script
(arm-elf-ld --verbose). The do not "effect" the generated binary and
AFAIK are for entries in the elf-file used by debuggers.

Anyway: I hope someone how knows more than I do can jump in here. Maybe
you can ask on the gcc and/or binutils mailing-lists.

> Also, what generally goes shoved in the .edata section?

I don't see such a section in the script. Just a symbol. This symbol
will be used by the startup-code to copy initialization values from ROM
to RAM.

> Sorry, linker scripts were foreign to me (and I'm still learning). They
> always just worked until now :-)

So what is not working for you now?

For debugging: let the compiler leave the assembler-files, create a
symbol-file, a map-file and the disassembly for the complete build
(objdump). Esp. the map-file and disassembly are very useful to locate
problems - at least they are for me.

Martin Thomas

> Well, I don't know the meaning of all those entries too. Usually I try
> to take already available example linker-scripts for the target(-family)
> and the default linker-script as templates and modify or reduce them to
> my needs. The manual of the GNU-linker has some useful information. You
> may also find information on them in the "gcc internals" documentation
> available from gcc.gnu.org.

A lot of it seems to have to do with the original system architecture
the guys were going for, and generally this stuff isn't documented too
well in opensource code!

>
> Just a few remarks:
> - The compiler places interface-functions for needed for interworking in
> .glue*
> - As far as I know linkonce* tells the linker to link identical elements
> only once
> - The debugger sections can be copied from the default linker-script
> (arm-elf-ld --verbose). The do not "effect" the generated binary and
> AFAIK are for entries in the elf-file used by debuggers.


Sorry for the complete ignorance, what do you mean by "interworking"
As for the debugger stuff, sweet! That's a relief

>
> Anyway: I hope someone how knows more than I do can jump in here. Maybe
> you can ask on the gcc and/or binutils mailing-lists.
>
>> Also, what generally goes shoved in the .edata section?
>
> I don't see such a section in the script. Just a symbol. This symbol
> will be used by the startup-code to copy initialization values from ROM
> to RAM.

I found a reference on a 68hc11 linker page that says its a symbol for
"end of data". Assuming this is true, that would point to the first
empty spot in ram, right?

>
>> Sorry, linker scripts were foreign to me (and I'm still learning). They
>> always just worked until now :-)
>
> So what is not working for you now?

I'm trying to get a bootloader working which works on one version of
tinyos which has a different linker script, so I need to figure out what
everything does before I start breaking stuff!

>
> For debugging: let the compiler leave the assembler-files, create a
> symbol-file, a map-file and the disassembly for the complete build
> (objdump). Esp. the map-file and disassembly are very useful to locate
> problems - at least they are for me.

To do this, it's just objdump right? Or is there a different gnu
assembler command i need?

Thanks a bunch,
Federico

> Sorry for the complete ignorance, what do you mean by "interworking"

ARM7 (and maybe others) support two instruction-sets ARM and Thumb. Read
the documents available from arm.com for further information. Functions
in .glue are generated if ARM-code calls a Thumb-code and vice-versa.

> I found a reference on a 68hc11 linker page that says its a symbol for
> "end of data".

Read the startup-code and you will see how the symbol is used

> Assuming this is true, that would point to the first
> empty spot in ram, right?

Usually its the last address of the ROM-"image" of initialized data. Try
to understand the "memcpy"-loop for .data in the startup-code. Create a
symbol-file and you will see the address edata holds.

>> For debugging: let the compiler leave the assembler-files, create a
>> symbol-file, a map-file and the disassembly for the complete build
>> (objdump). Esp. the map-file and disassembly are very useful to locate
>> problems - at least they are for me.
>
> To do this, it's just objdump right? Or is there a different gnu
> assembler command i need?

objdump to create the disassembly for the elf-file. nm to create the
symbol-file, -Map linker-option to create the map-file.

Hi Martin,
Thank you for all of your replies, I'll get to tinker some more in the
next few days, other work has piled up! As for the interworking code, I
completely forgot about thumb mode (we don't use it)!

Thanks again!
Federico

Martin Thomas wrote:
>> Sorry for the complete ignorance, what do you mean by "interworking"
>
> ARM7 (and maybe others) support two instruction-sets ARM and Thumb. Read
> the documents available from arm.com for further information. Functions
> in .glue are generated if ARM-code calls a Thumb-code and vice-versa.
>
>> I found a reference on a 68hc11 linker page that says its a symbol for
>> "end of data".
>
> Read the startup-code and you will see how the symbol is used
>
>> Assuming this is true, that would point to the first
>> empty spot in ram, right?
>
> Usually its the last address of the ROM-"image" of initialized data. Try
> to understand the "memcpy"-loop for .data in the startup-code. Create a
> symbol-file and you will see the address edata holds.
>
>>> For debugging: let the compiler leave the assembler-files, create a
>>> symbol-file, a map-file and the disassembly for the complete build
>>> (objdump). Esp. the map-file and disassembly are very useful to locate
>>> problems - at least they are for me.
>>
>> To do this, it's just objdump right? Or is there a different gnu
>> assembler command i need?
>
> objdump to create the disassembly for the elf-file. nm to create the
> symbol-file, -Map linker-option to create the map-file.