Arm gnu directive assembler problem

Hi,

I' ve a problem with creating a new section with gnu gcc assembler for an ARM7TDMI.

I' ve a link script which I add IntFLASH2 and text2 sections

MEMORY { IntFLASH (rx) : ORIGIN = 0x00080000, LENGTH = 0x10000 IntFLASH2 (rx) : ORIGIN = 0x0090000, LENGTH = 0x10000 IntRAM (rw) : ORIGIN = 0x00010000, LENGTH = 8192 }

SECTIONS { .text : { *startup.o (.text) /* Startup code */ *(.text) /* remaining code */

*(.glue_7t) *(.glue_7) } >IntFLASH

. = ALIGN(4);

.text2 : { *(.text) } >IntFLASH2

. = ALIGN(4); ... }

and when I want to use this section like that

.text .arm

.global _startup .func _startup

...

.size _startup, . - _startup .endfunc

.section .text2 data0 .word 0x12345678

.end

there is an error

and if I remove the dot before text2 compilation and link are ok but text2 section doesn' t seems to exists.

Thanks for ideas.

Reply to
pes
Loading thread data ...

What is the error?

Do you remove the dot in the linker script as well?

Doesn't exist where?

If you want the contents of the section to show up in hex files and linker output, you probably need to set the section attributes like this:

.section .text2,"a",@progbits

Technically, you probably should be using an "x" flag for a text section as well. It seems to work fine without it, but it's the right thing to do:

.section .text2,"ax",@progbits For a writable section, add a w to the flags string.

You might want to do

$ into as

and read the stuff on the .section directive.

--
Grant Edwards                   grante             Yow!  .. If I had heart
                                  at               failure right now,
                               visi.com            I couldn't be a more
                                                   fortunate man!!
Reply to
Grant Edwards

Um, make that "info as"

-- Grant Edwards grante Yow! FUN is never having at to say you're SUSHI!! visi.com

Reply to
Grant Edwards

There is an error on the .end line, I' ve no more description

No, not in the script

The value isn' t in memory when the program is loaded

There is no change, but I use .section .text2,"ax","progbits" for syntax

Yes, but I' m a little embarassed I don' t see any examples with sections other than standard text bss & data.

Thanks for you interest

Reply to
pes

It's pretty hard to help if you can't post the actuall error mesage.

The names in the linker script have to match the names in the assembly file.

Is it in the object file output by the assember? Is it in the final object file output by the linker? How do you load the program in to memory?

First, check the object file that the assembler generates using arm-elf-objdump --section-headers. Then check the object file produced by the linker using the same command.

What version of binutils are you using?

`.section NAME' ===============

Use the `.section' directive to assemble the following code into a section named NAME.

This directive is only supported for targets that actually support arbitrarily named sections; on `a.out' targets, for example, it is not accepted, even with a standard `a.out' section name.

[COFF stuff deleted]

ELF Version

-----------

This is one of the ELF section stack manipulation directives. The others are `.subsection' (*note SubSection::), `.pushsection' (*note PushSection::), `.popsection' (*note PopSection::), and `.previous' (*note Previous::).

For ELF targets, the `.section' directive is used like this:

.section NAME [, "FLAGS"[, @TYPE[, @ENTSIZE]]]

The optional FLAGS argument is a quoted string which may contain any combination of the following characters: `a' section is allocatable

`w' section is writable

`x' section is executable

`M' section is mergeable

`S' section contains zero terminated strings

The optional TYPE argument may contain one of the following constants: `@progbits' section contains data

`@nobits' section does not contain data (i.e., section only occupies space)

Note on targets where the `@' character is the start of a comment (eg ARM) then another character is used instead. For example the ARM port uses the `%' character.

If FLAGS contains `M' flag, TYPE argument must be specified as well as ENTSIZE argument. Sections with `M' flag but not `S' flag must contain fixed size constants, each ENTSIZE octets long. Sections with both `M' and `S' must contain zero terminated strings where each character is ENTSIZE bytes long. The linker may remove duplicates within sections with the same name, same entity size and same flags.

If no flags are specified, the default flags depend upon the section name. If the section name is not recognized, the default will be for the section to have none of the above flags: it will not be allocated in memory, nor writable, nor executable. The section will contain data.

For ELF targets, the assembler supports another type of `.section' directive for compatibility with the Solaris assembler:

.section "NAME"[, FLAGS...]

Note that the section name is quoted. There may be a sequence of comma separated flags: `#alloc' section is allocatable

`#write' section is writable

`#execinstr' section is executable

This directive replaces the current section and subsection. The replaced section and subsection are pushed onto the section stack. See the contents of the gas testsuite directory `gas/testsuite/gas/elf' for some examples of how this directive and the other section stack directives work.

--
Grant Edwards                   grante             Yow!  I feel... JUGULAR...
                                  at               
                               visi.com
Reply to
Grant Edwards

What happens if you change this to

*(.text2) = to match the assembler section directive!

....

.....

The exact error message would help.

Because it more than likely has dumped it in the text section, what does the MAP file show for where they are put, (not what is in text2 section).

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate
Reply to
Paul Carpenter

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.