> On Tuesday, May 4, 2021 at 6:26:44 PM UTC-7, Don Y wrote:
> > On 5/4/2021 6:06 PM, Ed Lee wrote:
> > > I am just trying to convince myself how is that possible to work without the
> > > assembler knowing the actual physical address of ram.
> > "RAM" is just a set of one (or more) labels that you have located in a data
> > segment.
> >
> > How does the assembler know how to access a subroutine that you've defined IN
> > ANOTHER MODULE?
>
> The compiler tell the linker to relocate address of another module, as well as address of data variables. But it does not change the content of such variables, even if they are relocated to another address space. In this case, if the assembler is using the content of the variable pointing to the data variable's address, it would remain in the rom space.
What you wrote is confused. After assembly main part of .o is
preliminary content which will go to the executable. This is
preliminary is sense that there are holes to be filled by the
linker. For linker it does not matter much if hole is part
of instruction or content of "variable" (I wrote variable in
quotes because if it goes to ROM it can not change, but for
linker it does not matter much). Another part of object
file (relocation table) gives formulas which tell linker
how to compute values needed to fill holes. I wrote
formulas because there is some calculation, but it
is rather simple. Some values may be (absolute) constants
defined in other files. Some are of form "start address
of module + offset" (offset inside module is known at
assembly time, start address is known only at link
time). To make it more concrete look at part of
disassembly from example that I provided earlier:
from .o file:
00000200 <start>:
200: 4a02 ldr r2, [pc, #8] ; (20c <start+0xc>)
202: 6813 ldr r3, [r2, #0]
204: 3301 adds r3, #1
206: 6013 str r3, [r2, #0]
208: e7fb b.n 202 <start+0x2>
20a: bf00 nop
20c: 00000000 andeq r0, r0, r0
You see that addresses are just offsets from start of file,
instruction at offset 200 loads word at offset 20c.
Content of this word is not known at assembly time, so
objdump shows it as 0.
Now the same from .elf file:
08000200 <start>:
8000200: 4a02 ldr r2, [pc, #8] ; (800020c <start+0xc>)
8000202: 6813 ldr r3, [r2, #0]
8000204: 3301 adds r3, #1
8000206: 6013 str r3, [r2, #0]
8000208: e7fb b.n 8000202 <start+0x2>
800020a: bf00 nop
800020c: 20000000 andcs r0, r0, r0
Linker shifted object file to start of ROM, so now we have
instruction at absolute address 8000200 which loads word from
address 800020c. Linker knows that this word is address of
variable c, which goes to RAM at 20000000, so linker changes
(fixes) content of constant at 800020c to 20000000.
Note that 411 starts with uninitialized RAM. If you want
to initialize variables in RAM, you need to put initial
values in ROM and initialization code of your program
have to copy initial values to RAM. If you use normal
embedded toolchain, your toolchain will provide starup
routine which responsible for initializing variables
and few other things expected by C code. If you want
pure assembler you need to provide your own initialization
(my example was done in way which needs no extra
initialization, but it is doing nothing interesting,
just sits in infinite loop incrementing variable).
For debugging using gdb you can load data (or program)
to RAM (and linker supports this), but this depends
in debugging interface. In context of classical OS,
operating system loads program to RAM. Linker does
not care much if section goes to ROM or RAM. Linker
simply puts specified sections in ELF executable
and fills holes according to rules (which may be
more complicated than exaples I gave, but not
very complicated).
--
Waldek Hebisch
Reply by Don Y●May 4, 20212021-05-04
On 5/4/2021 6:33 PM, Ed Lee wrote:
> On Tuesday, May 4, 2021 at 6:26:44 PM UTC-7, Don Y wrote:
>> On 5/4/2021 6:06 PM, Ed Lee wrote:
>>> I am just trying to convince myself how is that possible to work without
>>> the assembler knowing the actual physical address of ram.
>> "RAM" is just a set of one (or more) labels that you have located in a
>> data segment.
>>
>> How does the assembler know how to access a subroutine that you've defined
>> IN ANOTHER MODULE?
>
> The compiler tell the linker to relocate address of another module, as well
> as address of data variables. But it does not change the content of such
> variables, even if they are relocated to another address space. In this
> case, if the assembler is using the content of the variable pointing to the
> data variable's address, it would remain in the rom space.
If you define a variable in a section that is bound to a ROM portion
of your address space, then the variable *is* in the ROM -- effectively
"immutable". (this is useful in preference to #defines)
If it is *really* a "variable", then you have two types to deal with:
initialized and uninitialized. (ignoring stack frames)
An uninitialized variable just takes up space in RAM; there is no
need to store the "initial value" for that variable. You just
need to know where -- in the .bss segment -- the variable is
implemented. You can reduce the size of an executable by putting
all "uninitialized" data into a single .bss (conventionally) section.
The startup code typically "zeroes" all of the bss segment. Note
that is usually does this as efficiently as possible -- bzero()
just jams zeroes into a *region* of memory with no concern over
the "variable boundaries" within it.
On the other hand, *initialized* data (variables) need to take up space
in ROM (for the initial value) as well as RAM (for the *actual* variable
which can be ALTERED, at run time).
These (the "live" variables modifiable at run time) reside in the .data
segment.
The constant values with which they should be initialized are copied
into this segment by the startup code -- before "your" code runs.
Again, the startup code doesn't have to respect the individual
boundaries of variables; it just has to ensure that, once done,
every variable referenced in that section has the correct
initial value.
[E.g., I can jam 0x41424344 into a word and this might correspond to
four characters of a string ("ABCD"), two shorts (0x4142 and x4344),
etc. The initialization code will just copy a block of constants
into the writable memory set aside for those "initialized data" as
efficiently as possible]
Actual "const" values are stored in a .rodata segment which, ideally,
can not be altered (but, that's up to the hardware).
You don't care where *the* constant value is stored that will be used to
initialize "foo" in "int foo = 123;". That value will be copied *into*
foo before your code runs -- ONCE!
But, you *do* care where "foo" actually resides because your code will
reference it -- REPEATEDLY.
Using these segments/sections, you can strategically rearrange
where your resources are allocated. I recall a legacy compiler that
placed a 64KB limit on the amount of data that were supported.
But, treated consts as a *separate* 64KB segment. So, I could
effectively have 128KB of "data" addressable without exceeding
the limitations of the compiler.
Reply by Ed Lee●May 4, 20212021-05-04
On Tuesday, May 4, 2021 at 6:26:44 PM UTC-7, Don Y wrote:
> On 5/4/2021 6:06 PM, Ed Lee wrote:
> > I am just trying to convince myself how is that possible to work without the
> > assembler knowing the actual physical address of ram.
> "RAM" is just a set of one (or more) labels that you have located in a data
> segment.
>
> How does the assembler know how to access a subroutine that you've defined IN
> ANOTHER MODULE?
The compiler tell the linker to relocate address of another module, as well as address of data variables. But it does not change the content of such variables, even if they are relocated to another address space. In this case, if the assembler is using the content of the variable pointing to the data variable's address, it would remain in the rom space.
Reply by Don Y●May 4, 20212021-05-04
On 5/4/2021 6:06 PM, Ed Lee wrote:
> I am just trying to convince myself how is that possible to work without the
> assembler knowing the actual physical address of ram.
"RAM" is just a set of one (or more) labels that you have located in a data
segment.
How does the assembler know how to access a subroutine that you've defined IN
ANOTHER MODULE?
The linkage editor knows how to resolve cross-module labels.
So, you can reference a location in "ROM" or "RAM" without
the actual instruction knowing the difference.
The loader maps addresses of sections to physical addresses.
So, you end up with a binary that has been *bound* to a specific
set of constraints -- inter-module and inter-section.
Reply by Ed Lee●May 4, 20212021-05-04
On Tuesday, May 4, 2021 at 5:21:46 PM UTC-7, anti...@math.uni.wroc.pl wrote:
> Ed Lee <edward....@gmail.com> wrote:
> > On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, anti...@math.uni.wroc.pl wrote:
> > > Ed Lee <edward....@gmail.com> wrote:
> > > > On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:
> > > > > Ed Lee <edward....@gmail.com> wrote:
> > > > > > On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:
> > > > > > > On 4.5.21 16.32, Ed Lee wrote:
> > > > > > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:
> > > > > > > >> On 3.5.2021 22:14 PM, Ed Lee wrote:
> > > > > > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:
> > > > > > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:
> > > > > > > >>>>> On 3.5.21 17.35, Ed Lee wrote:
> > > > > > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file?
> > > > > > > Please show the exact command line you're using for the as, so we can
> > > > > > > correct it. If you're using GCC to assemble a .s or .S file, the
> > > > > > > normal switches apply.
> > > > > >
> > > > > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld
> > > > > Looks OK
> > > > > > user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld
> > > > > > arm-none-eabi-as: unrecognized option '-T'
> > > > > >
> > > > > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld
> > > > > Given correct main.o shoud be OK.
> > > > > > > There is a good reason to use the assembler only to create the .o file
> > > > > > > and make the linking in a separate step (using gcc again).
> > > > > > >
> > > > > > > Please remove the .org directives from your assembler code. The linker
> > > > > > > script is the proper way to locate various program sections. If you
> > > > > >
> > > > > > But gcc-as generates the wrong addresses with memory access.
> > > > > If you write correct asm your addresses will be correct.
> > > > >
> > > > > Look at following:
> > > > > ----------------<cut here>--------------------
> > > > >
> > > > > .syntax unified
> > > > > .cpu cortex-m4
> > > > >
> > > > > .text
> > > > > .Lstack:
> > > > > .word 0x20020000
> > > > > .Lstart:
> > > > > .word start
> > > > >
> > > > > .text
> > > > > .org 512
> > > > > .global start
> > > > > .thumb
> > > > > .thumb_func
> > > > > .type start, %function
> > > > > start:
> > > > > ldr r2, .L4
> > > >
> > > > r2 = 550 (aprox)
> > > Wrong, this is PC relative load that load value stored at .L4,
> > > that is 0x20000000 (address of c).
> >
> > PC is approx 520. The assembler does not know about 0x20000000.
> Have you tried provided commands? There is also objdump, run
>
> arm-none-eabi-objdump -D anull.elf
>
> to see what is in .elf file. And compare with
>
> arm-none-eabi-objdump -D anull.o
>
> And yes, assember produces relocatable code and does not know
> addresses. It is linker job to put addresses into ELF executable.
Yes, i have been looking at object files, elf and bin files, with objdump, readelf, od and hexdump. The linker relocates the data to the ram address, but does not change the content, which is still pointing to the rom address.
I am just trying to convince myself how is that possible to work without the assembler knowing the actual physical address of ram.
Reply by ●May 4, 20212021-05-04
Ed Lee <edward.ming.lee@gmail.com> wrote:
> On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, anti...@math.uni.wroc.pl wrote:
> > Ed Lee <edward....@gmail.com> wrote:
> > > On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:
> > > > Ed Lee <edward....@gmail.com> wrote:
> > > > > On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:
> > > > > > On 4.5.21 16.32, Ed Lee wrote:
> > > > > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:
> > > > > > >> On 3.5.2021 22:14 PM, Ed Lee wrote:
> > > > > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:
> > > > > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:
> > > > > > >>>>> On 3.5.21 17.35, Ed Lee wrote:
> > > > > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file?
> > > > > > Please show the exact command line you're using for the as, so we can
> > > > > > correct it. If you're using GCC to assemble a .s or .S file, the
> > > > > > normal switches apply.
> > > > >
> > > > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld
> > > > Looks OK
> > > > > user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld
> > > > > arm-none-eabi-as: unrecognized option '-T'
> > > > >
> > > > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld
> > > > Given correct main.o shoud be OK.
> > > > > > There is a good reason to use the assembler only to create the .o file
> > > > > > and make the linking in a separate step (using gcc again).
> > > > > >
> > > > > > Please remove the .org directives from your assembler code. The linker
> > > > > > script is the proper way to locate various program sections. If you
> > > > >
> > > > > But gcc-as generates the wrong addresses with memory access.
> > > > If you write correct asm your addresses will be correct.
> > > >
> > > > Look at following:
> > > > ----------------<cut here>--------------------
> > > >
> > > > .syntax unified
> > > > .cpu cortex-m4
> > > >
> > > > .text
> > > > .Lstack:
> > > > .word 0x20020000
> > > > .Lstart:
> > > > .word start
> > > >
> > > > .text
> > > > .org 512
> > > > .global start
> > > > .thumb
> > > > .thumb_func
> > > > .type start, %function
> > > > start:
> > > > ldr r2, .L4
> > >
> > > r2 = 550 (aprox)
> > Wrong, this is PC relative load that load value stored at .L4,
> > that is 0x20000000 (address of c).
>
> PC is approx 520. The assembler does not know about 0x20000000.
Have you tried provided commands? There is also objdump, run
arm-none-eabi-objdump -D anull.elf
to see what is in .elf file. And compare with
arm-none-eabi-objdump -D anull.o
And yes, assember produces relocatable code and does not know
addresses. It is linker job to put addresses into ELF executable.
--
Waldek Hebisch
Reply by Don Y●May 4, 20212021-05-04
On 5/4/2021 4:14 PM, antispam@math.uni.wroc.pl wrote:
> Don Y <blockedofcourse@foo.invalid> wrote:
>> On 5/4/2021 12:22 PM, antispam@math.uni.wroc.pl wrote:
>>> AFAICS it generates .elf file as you want. There is little
>>> weirdness with interrupt vectors: Tauno Voipio wanted vectors
>>> in separate section but I normally put them in .text,
>>> so using his linker script with my asm gives empty .romvec.
>>> Above I put just two vectors (should be enough to run) but
>>> in something serious there would be a subsection (written
>>> in C).
>>
>> In general (since forever) you can't go wrong with MORE sections.
>> This makes the layout of the code visible to the link/load phase.
>>
>> I put the *ROM* copy of vectors in one section and the *RAM*
>> copy in another (as the code will switch to the RAM copy once
>> the ROM image has been verified and RAM initialized, program
>> loaded, etc.).
>>
>> Likewise, the boot loader, BIST, etc.
>
> You probably imagine something more complicated than STM32F411.
I try to solve similar problems in very similar ways. So, I
don't have to explain why I did "something different" in one
case (but not another).
>> This lets you juggle where things should "fit" in the final image
>> instead of having to examine the code, itself, to determine the
>> structure. The tools are already there; let them do the work.
>>
>> [It also makes it easier to reuse "sections" from one project
>> to the next]
>
> The example is a toy which IMO fulfils its purpose. As I wrote
> I have vectors as subsection, in linker script I can put it
> where I want it, simply to the moment it was most convenient
> to put it in .text. With my setup I can link .text so that
> it goes to RAM, which is convenient for debugging small programs
> or to ROM (usual setup). Script provided by Tauno Voipio
> creates overlapped sections in final executable, I do not
> know why. I can imagine use of overlapped sections in RAM,
> but what they buy in ROM?
I've not examined the post so can't comment on specifics.
As to overlaying "ROM", I've done so (ages ago) in the
era of bank-switched hardware -- switching ROM *out* of
an address space after POST so those reserved locations
(common in smaller MPUs) could be more effectively used
(out of RAM).
Likewise, swapping banks of RAM into portions of the
logical address space (to support independent stacks
and heaps for many threads).
You can also overlay read and write accesses to portions
of an address space (e.g., read an address yields one
datum while writing drives another -- most common in
mapped I/O)
<shrug> Dunno.
But, in each case, doing it in the code makes the code
more brittle; if the address map changes, then the *code*
has to change. And, the change has to be ferreted out
(instead of exposed in a simple script).
> Personaly, I am trying to avoid unnecessary complexity.
> Currently linker scripts give me enough possibilities
> to rearrange code, so I felt no need to additionally
> juggle sections in executable (that would be different
> if an OS was present, but I am talking here about
> programs running on bare hardware).
Every project I've built runs on bare iron. Even my
current project has to install the POST/BIST/loader/etc.
on bare iron *before* it can load (over the wire) the
actual OS and, then, the application.
On reset, I have to ensure the initial PC, etc. is
available (from "ROM"). A small/tight checksum
routine to verify the next stage of boot is intact.
Then, code to verify the hardware can be used *by* that
next stage of the boot (i.e., do I have any functional
RAM?)
Eventually, invoking specific test routines for *this*
hardware (different set of I/Os than other devices running
the same boot code) by probing a portion of the address
space into which those ROM-based routines would exist.
All that before beginning to set up the environment and
network stack to download the OS image.
Plus, a "safe" copy of the boot loader so I can
reflash without fear of making a brick.
Having a "rich" structure/methodology to call upon for juggling
these various "boxes" makes it easier to add as new requirements
come along. And, exposes these details at a higher level
(so the Next Guy isn't scratching his head wondering
why "this is here" and "that is there").
[I.e., it's easier to document a script than it is to
embed lots of notes in a variety of different files and
HOPING the Next Guy can find all of them!]
Reply by ●May 4, 20212021-05-04
Don Y <blockedofcourse@foo.invalid> wrote:
> On 5/4/2021 12:22 PM, antispam@math.uni.wroc.pl wrote:
> > AFAICS it generates .elf file as you want. There is little
> > weirdness with interrupt vectors: Tauno Voipio wanted vectors
> > in separate section but I normally put them in .text,
> > so using his linker script with my asm gives empty .romvec.
> > Above I put just two vectors (should be enough to run) but
> > in something serious there would be a subsection (written
> > in C).
>
> In general (since forever) you can't go wrong with MORE sections.
> This makes the layout of the code visible to the link/load phase.
>
> I put the *ROM* copy of vectors in one section and the *RAM*
> copy in another (as the code will switch to the RAM copy once
> the ROM image has been verified and RAM initialized, program
> loaded, etc.).
>
> Likewise, the boot loader, BIST, etc.
You probably imagine something more complicated than STM32F411.
> This lets you juggle where things should "fit" in the final image
> instead of having to examine the code, itself, to determine the
> structure. The tools are already there; let them do the work.
>
> [It also makes it easier to reuse "sections" from one project
> to the next]
The example is a toy which IMO fulfils its purpose. As I wrote
I have vectors as subsection, in linker script I can put it
where I want it, simply to the moment it was most convenient
to put it in .text. With my setup I can link .text so that
it goes to RAM, which is convenient for debugging small programs
or to ROM (usual setup). Script provided by Tauno Voipio
creates overlapped sections in final executable, I do not
know why. I can imagine use of overlapped sections in RAM,
but what they buy in ROM?
Personaly, I am trying to avoid unnecessary complexity.
Currently linker scripts give me enough possibilities
to rearrange code, so I felt no need to additionally
juggle sections in executable (that would be different
if an OS was present, but I am talking here about
programs running on bare hardware).
--
Waldek Hebisch
Reply by Ed Lee●May 4, 20212021-05-04
On Tuesday, May 4, 2021 at 3:57:23 PM UTC-7, anti...@math.uni.wroc.pl wrote:
> Ed Lee <edward....@gmail.com> wrote:
> > On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:
> > > Ed Lee <edward....@gmail.com> wrote:
> > > > On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:
> > > > > On 4.5.21 16.32, Ed Lee wrote:
> > > > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:
> > > > > >> On 3.5.2021 22:14 PM, Ed Lee wrote:
> > > > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:
> > > > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:
> > > > > >>>>> On 3.5.21 17.35, Ed Lee wrote:
> > > > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file?
> > > > > Please show the exact command line you're using for the as, so we can
> > > > > correct it. If you're using GCC to assemble a .s or .S file, the
> > > > > normal switches apply.
> > > >
> > > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld
> > > Looks OK
> > > > user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld
> > > > arm-none-eabi-as: unrecognized option '-T'
> > > >
> > > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld
> > > Given correct main.o shoud be OK.
> > > > > There is a good reason to use the assembler only to create the .o file
> > > > > and make the linking in a separate step (using gcc again).
> > > > >
> > > > > Please remove the .org directives from your assembler code. The linker
> > > > > script is the proper way to locate various program sections. If you
> > > >
> > > > But gcc-as generates the wrong addresses with memory access.
> > > If you write correct asm your addresses will be correct.
> > >
> > > Look at following:
> > > ----------------<cut here>--------------------
> > >
> > > .syntax unified
> > > .cpu cortex-m4
> > >
> > > .text
> > > .Lstack:
> > > .word 0x20020000
> > > .Lstart:
> > > .word start
> > >
> > > .text
> > > .org 512
> > > .global start
> > > .thumb
> > > .thumb_func
> > > .type start, %function
> > > start:
> > > ldr r2, .L4
> >
> > r2 = 550 (aprox)
> Wrong, this is PC relative load that load value stored at .L4,
> that is 0x20000000 (address of c).
PC is approx 520. The assembler does not know about 0x20000000.
Reply by ●May 4, 20212021-05-04
Ed Lee <edward.ming.lee@gmail.com> wrote:
> On Tuesday, May 4, 2021 at 12:22:16 PM UTC-7, anti...@math.uni.wroc.pl wrote:
> > Ed Lee <edward....@gmail.com> wrote:
> > > On Tuesday, May 4, 2021 at 7:44:05 AM UTC-7, Tauno Voipio wrote:
> > > > On 4.5.21 16.32, Ed Lee wrote:
> > > > > On Tuesday, May 4, 2021 at 2:38:55 AM UTC-7, Tauno Voipio wrote:
> > > > >> On 3.5.2021 22:14 PM, Ed Lee wrote:
> > > > >>> On Monday, May 3, 2021 at 12:12:53 PM UTC-7, Ed Lee wrote:
> > > > >>>> On Monday, May 3, 2021 at 11:49:42 AM UTC-7, Tauno Voipio wrote:
> > > > >>>>> On 3.5.21 17.35, Ed Lee wrote:
> > > > >>>>>> What is the compiler option and/or directive to change the "Addr" field of elf file?
> > > > Please show the exact command line you're using for the as, so we can
> > > > correct it. If you're using GCC to assemble a .s or .S file, the
> > > > normal switches apply.
> > >
> > > user@user:~/mcu$ arm-none-eabi-gcc -g -Wall -nostdlib main.s -T stm.ld
> > Looks OK
> > > user@user:~/mcu$ arm-none-eabi-as -g main.s -T stm.ld
> > > arm-none-eabi-as: unrecognized option '-T'
> > >
> > > user@user:~/mcu$ arm-none-eabi-ld main.o -T stm.ld
> > Given correct main.o shoud be OK.
> > > > There is a good reason to use the assembler only to create the .o file
> > > > and make the linking in a separate step (using gcc again).
> > > >
> > > > Please remove the .org directives from your assembler code. The linker
> > > > script is the proper way to locate various program sections. If you
> > >
> > > But gcc-as generates the wrong addresses with memory access.
> > If you write correct asm your addresses will be correct.
> >
> > Look at following:
> > ----------------<cut here>--------------------
> >
> > .syntax unified
> > .cpu cortex-m4
> >
> > .text
> > .Lstack:
> > .word 0x20020000
> > .Lstart:
> > .word start
> >
> > .text
> > .org 512
> > .global start
> > .thumb
> > .thumb_func
> > .type start, %function
> > start:
> > ldr r2, .L4
>
> r2 = 550 (aprox)
Wrong, this is PC relative load that load value stored at .L4,
that is 0x20000000 (address of c).
> > .L2:
> > ldr r3, [r2]
>
> r3 = c
>
> > adds r3, r3, #1
>
> r3 = d
>
> > str r3, [r2]
>
> store d to memory location 550
>
> Segmentation violation. Can't write to ROM.
No, this is store to RAM (to c).
> > b .L2
> > .align 2
> > .L4:
> > .word c
> >
> > .comm c,4,4
> >
> > ----------------<cut here>--------------------
> >
> > Store to anull.s and do:
> >
> > arm-none-eabi-as -c anull.s -o anull.o
> > arm-none-eabi-ld anull.o -T f411.ld -o anull.elf
> >
> > AFAICS it generates .elf file as you want. There is little
> > weirdness with interrupt vectors: Tauno Voipio wanted vectors
> > in separate section but I normally put them in .text,
> > so using his linker script with my asm gives empty .romvec.
> > Above I put just two vectors (should be enough to run) but
> > in something serious there would be a subsection (written
> > in C).
> >
> > --
> > Waldek Hebisch