Searching for lib...

Mark Palmerino mbp@csr-bos.com
Tue Feb 27 14:14:00 GMT 2001


Hi Joel, Kai and all,

Thank you for your response - I appreciate the great willingness of many
people who are going out of their way to help me.

I will try to respond to the questions below:

> Ok, First to clarify. (My assumptions)
> 
> hello.map    is failed build map on unix system
> hell1.map     is successful map from windows tools system
> rm_rom.ld    is linker script used for both builds

The above are correct assumptions.

> ll        is working windows script for windows tools

ll is LL.BAT which calls ld and then objcopy.

> ??        script on unix

It is called 'compile.sh' and is a small script of my making to mimic the
steps that are taken on the windows system.


> Comments
> 1.    When building on unix system using rm_rom.ld you should not need or add
> any libraries (to the ld command line) as they are included by the GROUP
> command. (see the way ll does without)

I actually noticed that this morning. If I run the following ld command on
unix:

# m68k-coff-ld -v -o hello.cof -T rm_rom.ld -M > hello.map

I get the following:

rm_crt0.o:rm_crt0.S:149: undefined reference to `main'
./libc.a(exit.o)(.text+0x52):exit.c: undefined reference to `_exit'
./libc.a(sbrkr.o)(.text+0x12):sbrkr.c: undefined reference to `sbrk'

In the meantime, I have copied the entire "../mcpu32" directory from the
windows machine to a unix directory, and with the following command:


m68k-coff-ld -v -o hello.cof -L/hfs/mcpu32 -T rm_rom.ld -M > hello.map

I get the following:

rm_crt0.o:rm_crt0.S:149: undefined reference to `main'

So, there must be something else in that directory that is influencing the
link. Also, it should be noted that I can compile hello.c successfully in
unix - it is just that the resulting S-record file does not run on the
board. I wonder if this is related to the incorrect __vector*_defaults
mentioned below.


Please note that I also copied the rm_crt0.o file from the windows side, as
well.  In the map file from the above command, which is enclosed as an
attachment, I'm still getting the problem with the __vector*_defaults that
Joel pointed out.  Is there a reason for that?  I am also enclosing the
rm_crt0.S file if there might be a hint in that.


> 2.    The -L/usr/local/lib/gcc-lib/m68k-coff/2.8.1, ... library include paths
> should not be needed if
> your cross was built correctly and you did not change related things in the
> specs file. But it
> probably wont hurt if this is the correct directory.
> 3.    comparing the two map files after the line "Linker script and memory
map" 
> shows the attempt to
> load extra libs in hello.map.  note the different paths for the same
> libs(LOAD) But if you notice
> above that nothing was loaded from libbcc.a. This is why you have undefined
> references for _exit,
> sbrk, isatty, ...

Things are different with the use of the entire mcpu32 directory from
windows, there is just the one undefined reference - to 'main' coming from
rm_crt0.o.  Any suggestions for fixing that?

Another thing that bothers me is what seems to be a big difference reflected
in the .map files from the unix compile (hello.map) and the windows compile
(hell1.map). In hell1.map, many many different archive members are included
while far fewer are shown in hello.map - is this because the link for
hello.map was aborted due to the problem finding 'main'?

> 4.    Your rm_crt0.o are not the same! notice the differences for your
> __vector*_defaults in the two

Well, I brought the rm_crt0.S file over from windows and compiled it to
produce the rm_crt0.o. Is there something I should inspect in it to see why
this happens?

As mentioned above, I also brought over the rm_crt0.o file from windows, and
it still produces the same problem with the __vector*_defaults.  I don't
quite know where to turn at this point...



>> Here is rm_rom.ld (wrapping badly):
>> 
>> /*
>> * Linker script for typical ROM-based M68K embedded applications using COFF
>> obj format.
>> * Copyright © 1997-1999 by Object Software Inc., All Rights Reserved.
>> *
>> * The copyright holder hereby grants permission to use, copy, modify,
>> distribute,
>> * and license this software and its documentation for any purpose, provided
>> * that existing copyright notices are retained in all copies and that this
>> * notice is included verbatim in any distributions. No written agreement,
>> * license, or royalty fee is required for any of the authorized uses.
>> *
>> * This script needs four symbols defined to set the location of RAM and ROM
>> memory:
>> *    __rom_start        The first address of read-only memory.
>> *                All read-only sections are placed here, as well as
>> *                a copy of the initialized data to be copied to RAM
>> *                by the startup code.
>> *    __rom_size        the size of the read-only memory block.
>> *    __ram_start        The first address of read/write memory;
>> *                all initialized and uninitialized data goes here.
>> *    __ram_size        The size of the read/write memory block;
>> *                the stack pointer is set to the top of this block.
>> *
>> * In addition, the symbol __vector_default must be defined; this is the
>> address of
>> * the default interrupt/exception handler. Any interrupt vectors which do
>> not have
>> * a specific handler will be set to point to this location.
>> *
>> * These symbols may be defined on the linker command line or in an object
>> file.
>> *
>> * Stack grows down from high memory.
>> *
>> * The memory map look like this:
>> *
>> *          ROM
>> * +--------------------+ <- __rom_start
>> * | .vectors           |
>> * | .text              |
>> * |        _etext      |
>> * |        ctor list   | the ctor and dtor lists are for
>> * |        dtor list   | C++ support
>> * +--------------------+ <- __rom_data_start
>> * | ROM image of .data |
>> * +--------------------+
>> *
>> *          RAM
>> * +--------------------+ <- __ram_start
>> * | .data              | initialized data ends up here
>> * |        _edata      |
>> * +--------------------+
>> * | .bss               |
>> * |        __bss_start | start of bss, cleared by crt0
>> * |        _end        | start of heap, used by sbrk()
>> * +--------------------+
>> * .                    .
>> * .                    .
>> * .                    .
>> * |        __stack     | top of stack (at __ram_start + __ram_size)
>> * +--------------------+
>> */
>> STARTUP(rm_crt0.o)
>> OUTPUT_ARCH(m68k)
>> SEARCH_DIR(.)
>> /*
>> INPUT(vectors.o)
>> */
>> /*
>> GROUP(-ltrgt -lrom -lc -lgcc)
>> */
>> GROUP(-lbcc -lc -lgcc -lm)
>> __DYNAMIC  =  0;
>> 
>> __ram_start  = 0x03000;
>> __ram_size   = 0x05000;
>> __rom_start  = 0x90000;
>> __rom_size   = 0x70000;
>> __stack      = __ram_start + __ram_size - 0x4;
>> __prog_start = __rom_start + 0x10;
>> 
>> /*
>> * allocate the stack to be at the top of memory, since the stack
>> * grows down. __boot_stack is the stack pointer value that is stored
>> * in the exception vector table.
>> */
>> 
>> PROVIDE (__stack = __ram_start + __ram_size);
>> PROVIDE (__boot_stack = __ram_start + __ram_size);
>> 
>> /*
>> * Initalize some symbols to be zero so we can reference them in the
>> * crt0 without core dumping. These functions are all optional, but
>> * we do this so we can have our crt0 always use them if they exist.
>> * This is so BSPs work better when using the crt0 installed with gcc.
>> * We have to initalize them twice, so we cover a.out (which prepends
>> * an underscore) and coff object file formats.
>> */
>> PROVIDE (crt0_flags = 0);
>> PROVIDE (_crt0_flags = 0);
>> PROVIDE (hardware_init_hook = 0);
>> PROVIDE (_hardware_init_hook = 0);
>> PROVIDE (software_init_hook = 0);
>> PROVIDE (_software_init_hook = 0);
>> 
>> /* Provide default values for the interrupt/exception vectors.
>> * We have a unique name (in vectors.o) for each interrupt/exception vector.
>> * Any that are not explicitly defined in user code will be assigned a
>> default value
>> * by this series of PROVIDE directives.
>> */
>> 
>> /* .vectors, .text, and a copy of .data go into ROM; .data and .bss go into
>> RAM. */
>> SECTIONS
>> {
>> /*
>> .vectors __rom_start :
>> {
>> __vector_start = .;
>> *(.vectors)
>> }
>> */
>> 
>> /*
>> .text BLOCK (0x4) :
>> */
>> .text __rom_start :
>> {
>> LONG (0xbeefbeef);
>> LONG (__stack);
>> LONG (__prog_start);
>> LONG (0x0);
>> *(.text)
>> . = ALIGN(0x4);
>> __CTOR_LIST__ = .;
>> LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
>> *(.ctors)
>> LONG(0)
>> __CTOR_END__ = .;
>> __DTOR_LIST__ = .;
>> LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
>> *(.dtors)
>> LONG(0)
>> __DTOR_END__ = .;
>> *(.rodata)
>> *(.gcc_exc)
>> *(.gcc_except_table)
>> 
>> __INIT_SECTION__ = . ;
>> LONG (0x4e560000)    /* linkw %fp,#0 */
>> *(.init)
>> SHORT (0x4e5e)    /* unlk %fp */
>> SHORT (0x4e75)    /* rts */
>> 
>> __FINI_SECTION__ = . ;
>> LONG (0x4e560000)    /* linkw %fp,#0 */
>> *(.fini)
>> SHORT (0x4e5e)    /* unlk %fp */
>> SHORT (0x4e75)    /* rts */
>> 
>> /* hardware initialization lists go here */
>> . = ALIGN (0x4);
>> crt0_initialization_list = .;
>> _crt0_initialization_list = .;
>> *(.crt0ini)
>> . = ALIGN (0x2);
>> LONG (0)        /* null pointer terminates list */
>> _etext = .;
>> *(.lit)
>> . = ALIGN (0x4);
>> __data_start_rom = .;
>> }
>> 
>> .data __ram_start : AT (__data_start_rom)
>> {
>> __data_start = .;
>> *(.shdata)
>> *(.data)
>> _edata = .;
>> }
>> 
>> .bss BLOCK (0x4) :
>> {
>> __bss_start = . ;
>> *(.shbss)
>> *(.bss)
>> *(COMMON)
>> *(.eh_fram)
>> *(.eh_frame)
>> _end =  ALIGN (0x8);
>> __end = _end;
>> }
>> 
>> .stab 0 (NOLOAD) :
>> {
>> *(.stab)
>> }
>> 
>> .stabstr 0 (NOLOAD) :
>> {
>> *(.stabstr)
>> }
>> }
>> 
>> -----------------------------------------------------------------------------
>> -----------------------
>> Name: hello.map
>> hello.map    Type: Plain Text (text/plain)
>> Encoding: base64
>> 
>> Name: hell1.map
>> hell1.map    Type: Plain Text (text/plain)
>> Encoding: base64
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
> 
> 
> 



More information about the crossgcc mailing list