Feste Adressen in gnu ld

[Johannes (Gast)]

Hallo

Ich habe ein Assembler-Programm (68k) geschrieben, das aus drei Teilen 
besteht: Bootloader + Anwendung + Selbsttest. Nun möchte ich gerne jeden 
Teil an eine bestimmte Adresse legen:

0x00100 Bootloader
0x10000 Anwendung
0xA0000 Selbsttest

Kann mir bitte jemand sagen, wie ich das in GNU ld machen kann? 
Offensichtlich geht das per Linker Script (mein Default Script ist im 
Anhang). Was muss ich dort anpassen?

Grüße
Johannes

[Oliver S. (oliverso)]

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

Oliver

[Bauform B. (bauformb)]

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 (Gast)]

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

Leider nein.


Bauform B. schrieb:
> In so einem Fall mache ich daraus 3 eigenständige Programme mit jeweils
> einer anderen Basisadresse.

Das ist ein guter Workaround. Aber es muss doch auch eine richtige 
Lösung geben!


Kennt sich jemand mit gnu ld aus und hat jemand eine Idee?

[Johannes (Gast)]

Das scheint ja eine harte Nuss zu sein. Eigentlich ist die ja Aufgabe 
trivial, aber bei der Suche nach einer Lösung, wurde gleich auf das 
Linker-Script verwiesen und das ist leider nicht gerade selbsterklärend.

Gibt es denn niemanden, der sich mit dem Linker gut auskennt?

[Oliver S. (oliverso)]

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 (Gast)]

Oliver S. schrieb:
> Begründung?

https://stackoverflow.com/questions/31479054/is-there-something-like-org-for-nasm-in-gas

Oliver S. schrieb:
> 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?

Sie sind logisch in sich abgeschlossen, gehören semantisch aber 
zusammen. Es gibt Sprünge zwischen den Teilen. So, wie man es von einem 
ganz normalen Bootloader her kennt.

Meinst Du mit "Daten" die Konstanten?

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

Das glaube ich Dir aufs Wort. Aber meine Frage ist ja, wie ich das 
mache. Kannst Du mir da weiterhelfen? Was muss ich im Linker-Script 
abändern?

[Oliver S. (oliverso)]

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

[Bauform B. (bauformb)]

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.

[J. S. (jojos)]

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.

MEMORY
{
    FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 0x20000
    RAM (rwx) : ORIGIN = 0x20000000 + (((48 * 4) + 7) & 0xFFFFFFF8), LENGTH = 0x9000 - (((48 * 4) + 7) & 0xFFFFFFF8)
}

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.

ENTRY(Reset_Handler)
SECTIONS
{
    .text :
    {
        KEEP(*(.isr_vector))
        *(.text*)
        KEEP(*(.init))
        KEEP(*(.fini))
        *crtbegin.o(.ctors)
        *crtbegin?.o(.ctors)
        *(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
        *(SORT(.ctors.*))
        *(.ctors)
        *crtbegin.o(.dtors)
        *crtbegin?.o(.dtors)
        *(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
        *(SORT(.dtors.*))
        *(.dtors)
        *(.rodata*)
        KEEP(*(.eh_frame*))
    } > 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 (Gast)]

Oliver S. schrieb:
> 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

Ja, er gibt dann folgende Fehlermeldung aus: "MRI style ORG pseudo-op 
not supported".



Bauform B. schrieb:
> Als jemand, der keine Ahnung vom ld hat, finde
> ich, dass ein Script für dieses Programm viel kürzer sein sollte.

J. S. schrieb:
> so aufwändig habe ich das auch noch nicht gesehen, warum sind da z.B.
> die ganzen debug sections drin?

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.


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

Danke, ich werde das gleich ausprobieren!

[Oliver S. (oliverso)]

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

[... (Gast)]

Ich hab das fuer den PIC32/MIPS mit dem Linkerscript schon
hinbekommen. Da ging es bei mir darum, Code und Daten
auf eine bestimmte Adresse(n) im RAM zu legen.

Man muss fuer diese Teile dann eigene Scctions oder waren es
Regions(?) anlegen.

Ich guck mal ob ich das noch finde :).