This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Dec 21, 6:51pm, Michael Sokolov wrote: } Subject: Re: M68k a.out grief } "Holland, Alexander MHX" <HollaA@HPD.Abbott.com> wrote: } } > In order to use a particular in-circuit emulator, I switched from a GNU } > 2.95.2 m68k-coff target format to a GNU 2.95.2 m68k-aout format. } } Why would you do that? Your hardware can't possibly care or even know how you } use your GNU toolchain. Oh yes it can! He's talking about an in-circuit emulator - presumably used in conjunction with a source level debugger. You need to download the object code in a particular format to the emulator or it would understand what you're sending it. } > However, I } > am running into problems creating a linker script that provides even a } > minimum level of output section control. For example, my COFF script creates } > a ".vectors" section, specifies that the data part of my vectors module (a } > vector table data struct) go into this section, and locates the section at } > the base of ROM. The a.out linker seems not to allow me to specify any } > section different from the standard .text, .data, .bss. } } But this is the whole point of a.out and COFF! a.out .text, .data, and .bss } (and nothing else) by definition. COFF allows you to create your own sections } and that's what it was invented for in the first place. } } > Does anyone have any } > a.out linker script examples or techniques that provide more flexible output } > section control? } } This is impossible by definition. Well, I wouldn't state it quite so strongly. While it's true you can't have sections other than .text, .data and .bss, you can locate sections of code into different places *on a file or symbol basis* which should be sufficient for what he's trying to do. For instance, here's a linker script file we use (m68k-a.out): OUTPUT_FORMAT("a.out-sunos-big") OUTPUT_ARCH(m68k) SECTIONS { .text (TEXT) : { CREATE_OBJECT_SYMBOLS *(.text) _etext = ALIGN(4); } .data : { _sdata = .; *(.data) CONSTRUCTORS _edata = ALIGN(4); } .bss : { _sbss = .; *(.bss) _nvram = .; . = . + 2; process/o/nvdata.o (COMMON) _nvram_crc = .; . = . + 2; *(COMMON) _end = ALIGN(4); } } While this doesn't locate the vector table at the start of ROM, it does do some special things with the .bss section, like define the location of some global symbols and force the COMMON section of the nvdata.o file to be located after the .bss section and before all the other COMMON sections. So, you should be able to do something like this: .text (TEXT) : { CREATE_OBJECT_SYMBOLS vectors.o (.data) *(.text) _etext = ALIGN(4); } etc. to force the location of the data section of the vector table into the start of ROM. -Bill Randle Tektronix, Inc. billr@exgate.tek.com ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |