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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.