Feste Adressen in gnu ld

Reicht da nicht ein einfaches .org 0x42 im Programmcode?

Oliver

In so einem Fall mache ich daraus 3 eigenständige Programme mit jeweils 
einer anderen Basisadresse. Die 3 Hex-Dateien müssen/können dann einzeln 
programmiert werden. Falls der Programmspeicher sektorweise gelöscht 
werden kann, kann ich die auch einzeln updaten.

Johannes schrieb:
> Oliver S. schrieb:
>> Reicht da nicht ein einfaches .org 0x42 im Programmcode?
>
> Leider nein.

Begründung?

Ansonsten braucht es mehr Details. Sind das drei völlig eigenständige 
Programme, oder ist das ein Programm mit mehren Einsprungfunktionen? Wo 
sollen die Daten hin?

Johannes schrieb:
> aber bei der Suche nach einer Lösung, wurde gleich auf das
> Linker-Script verwiesen und das ist leider nicht gerade selbsterklärend.

Das ist aber nun mal die richtige Stelle, um dem linker die Verteilung 
von Code und Daten im Speicher vorzugeben.

Eine andere gibt es nicht.

Oliver

Johannes schrieb:
> Oliver S. schrieb:
>> Begründung?
>
> 
https://stackoverflow.com/questions/31479054/is-there-something-like-org-for-nasm-in-gas

Selbst schon ausprobiert? Es ist zwar richtig, daß .org die location nur 
nach vorne verlagern kann, aber die generelle Aussage dort, daß es wie 
beim NASM nicht mehr als einmal verwendet werden kann, ist falsch

https://ftp.gnu.org/old-gnu/Manuals/gas-2.9.1/html_chapter/as_7.html#SEC112

Im avr-as zumindest klappt das völlig problemlos. Was dein 68k-as daraus 
macht, keine Ahnung. Meine 68k-Zeiten waren im letzten Jahrtausend. Das 
ist aber doch schnell getestet.

Oliver

Johannes schrieb:
> Was muss ich im Linker-Script abändern?

Vielleicht (ja, nur ganz vielleicht) ist das das Problem. Also, das 
Script war mal für etwas völlig anderes gebaut worden und ist dann 42 
mal abgeändert worden? Als jemand, der keine Ahnung vom ld hat, finde 
ich, dass ein Script für dieses Programm viel kürzer sein sollte.

Aus dem Grund hatte ich für meine uC-Programme das Script komplett neu 
gebaut, angefangen bei Null. Und jetzt sieht es völlig anders aus als 
deins, gerade mal das SECTION statement habe ich noch wiedererkannt ;)

Was ich nur sagen will: es könnte evt. einfacher sein, bei Null 
anzufangen.

so aufwändig habe ich das auch noch nicht gesehen, warum sind da z.B. 
die ganzen debug sections drin? Die habe ich beim Cortex-M auch so im 
.elf drin.

Ich kenne das so das erstmal mit MEMORY die vorhandenen Speicherbereiche 
festgelegt werden, für Bootloader und App sind diese dann verschieden.

1

MEMORY

2

{

3

    FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 0x20000

4

    RAM (rwx) : ORIGIN = 0x20000000 + (((48 * 4) + 7) & 0xFFFFFFF8), LENGTH = 0x9000 - (((48 * 4) + 7) & 0xFFFFFFF8)

5

}

Ram ist hier nur verschoben weil da die Vectortabelle liegt. Mit der 
Flashstartadresse wäre das der Bootloader, die App liegt dann mit einem 
Offset dahinter.
Die Sections die danach folgen werden dann in die Memorybereiche gelegt.

1

ENTRY(Reset_Handler)

2

SECTIONS

3

{

4

    .text :

5

    {

6

        KEEP(*(.isr_vector))

7

        *(.text*)

8

        KEEP(*(.init))

9

        KEEP(*(.fini))

10

        *crtbegin.o(.ctors)

11

        *crtbegin?.o(.ctors)

12

        *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)

13

        *(SORT(.ctors.*))

14

        *(.ctors)

15

        *crtbegin.o(.dtors)

16

        *crtbegin?.o(.dtors)

17

        *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)

18

        *(SORT(.dtors.*))

19

        *(.dtors)

20

        *(.rodata*)

21

        KEEP(*(.eh_frame*))

22

    } > FLASH

Aus dem Linkerfile können noch Symbole exportiert werden die dann im 
Code verwendet werden können, um nicht zwei Stellen zu haben die manuell 
gleich gehalten werden müssen.

Johannes schrieb:
> Das ist das Default Linker-Script, dass ld ausgibt, wenn man es mit dem
> Parameter "-verbose" startet. Dass es so komplex ist, überrascht mich
> ebenfalls.

Das ist ein linkerscript für die C/C++-Toolchain. Die allermeisten Dinge 
da drin brauchst du für ein reines Assemblerprogramm nicht.

Das .org nicht funktioniert, liegt anscheinend am MRI-Mode.

https://web.mit.edu/rhel-doc/3/rhel-as-en-3/m.html

Wenn du keine Möglichkeit hast, den zu vermeiden, gehst halt damit 
nicht.

Oliver