hallo,
kann mir jemand erläutern, wie das linken, besipeislweise der allseits
beliebten bootloader-section, von statten geht?
ich bin darüber gestolpert, dass in den linker-scripts (avr5) meines
erachtens nach nichts von "unbekannten" sektionen steht. da steht text,
data, bss und so weiter.
wäre wirklich super, wenn mir da jemand erleuchtung verschaffen könnte.
ganz kurz reicht allemal. hintergrund ist, dass ich ein eigenes
linker-script entwickeln muss, da ist ein wenig (mehr) verständnis
sicherlich ganz hilfreich.
vielen dank,
bye kosmo
Das Linker-Map-File sowie die Doku zum GNU ld dürften dann für dich
interessant sein.
Meines Erachtens funktioniert das, da du die Adresse deiner selbst
erfundenen section eben einfach explizit angibst. Solange diese
nicht überlappt, wird sie akzeptiert.
hallo,
ja, sicher, schon beim lesen :)
aber vom linker-script werden eigene sections nicht explizit
berücksichtigt.
das einzige, was ich mir jetzt vorstellen tue ist, dass nicht
aufgeführte sections implizit nach allen anderen im linker-script
behandelt werden. so ist dass, wenn man auf die sections verzichtet:
http://www.delorie.com/gnu/docs/binutils/ld_18.html
weiteres habe ich noch nicht in erfahrung bringen können.
nichtsdestotrotz denke,
bye kosmo
hallo,
gut, weiter im .text
sämtliche unbekannten sections werden ganz am ende behandelt und
angefügt. ok, akzeptiert.
damit ergibt sich ein problem des linker-scripts (bei mir avr5.x):
verschiebe ich die dedizierte section nicht in einen freien bereich,
gibt's schelte vom linker. beispiel:
section .bootloader [000026bc -> 0000298b] overlaps section .data
[000026bc -> 000027c3]
ohne den section-start-switch des ld
warum? weil der location-pointer im linker-script nach der behandlung
von .text nicht weiter gesetzt wird.
ist das so gewollt? falls nein: sollte man (wer? :) ) das vielleicht
nicht korrigieren?
bye kosmo
in meinem jugendlichen leichtsinn würde ich einfach
. = __data_load_end
vorschlagen. gut, das geht nicht, weil danach noch was kommt, noinit und
eeprom.
aber das probiere ich mal aus.
gut, ok.
mit hilfe bin ich einen schritt weiter.
bisher ist mir aufgefallen, dass im linker-script nicht definierte
sectionen hinter .text angehangen werden. per default. dies konnte ich
mir nicht erklären. das gab ärger.
wesentlich sind die attribute der definierten MEMORY's:
text (rx) : ORIGIN = 0, LENGTH = 128K
data (rw!x) : ORIGIN = 0x800060, LENGTH = 0xffa0
eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 64K
die unbekannten sectionen sind executable geflaggt. einziger speicher,
welcher das laut linker-script auch bietet, ist text. ergo wird an den
location-pointer von text angehangen. daher der clash mit .data
was aus sicht des linkers funktioniert, ist folgendes:
unknown(rx) : ORIGIN = 0x820000, LENGTH = 128K
text (rx) : ORIGIN = 0, LENGTH = 128K
data (rw!x) : ORIGIN = 0x800060, LENGTH = 0xffa0
eeprom (rw!x) : ORIGIN = 0x810000, LENGTH = 64K
man bietet einen dummy-MEMORY, der executable ist. damit landen alle
unbekannten sectionen in "unknown". da dieses voher noch nicht verwendet
wurde, schliesst sich dessen location-pointer an data an:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .data PROGBITS 00800100 0027c6 000108 00 WA 0 0 1
[ 2] .text PROGBITS 00000000 0000b4 002712 00 AX 0 0 1
[ 3] .bss NOBITS 00800208 0028ce 00020f 00 WA 0 0 1
[ 4] .stab PROGBITS 00000000 002ba8 00978c 0c 5 0 4
[ 5] .stabstr STRTAB 00000000 00c334 00599d 00 0 0 1
[ 6] .bootloader PROGBITS 00820000 0028ce 0002d8 00 AX 0 0 1
[ 7] .shstrtab STRTAB 00000000 011cd1 000047 00 0 0 1
[ 8] .symtab SYMTAB 00000000 011ea8 0019c0 10 9 256 4
[ 9] .strtab STRTAB 00000000 013868 000e16 00 0 0 1
text geht von 0 bis 0x2712, data von 0x2712 bis 0x28ce, bss steht auf
0x282e, danach kommt die beispielhafte bootloader-section von 0x28ce bis
irgendwas.
soweit, so gut. keine ahnung, ob der code läuft :)
unschön ist auch, das bei explizitem platzieren der unbekannten sections
die bss sich hinten anschliesst. also am beispiel
--section-start=.bootloader=0x1E000
schliesst sich an .data 0x28ce die .bootloader an. sind ja nur offsets
im elf, im .map steht schon die richtige adresse:
.bootloader 0x0001e000 0x2d8
any hints? rfc.
bye kosmo
