wie funktioniert das -WL,--section-start

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