Re: FW: Searching for lib...

[Joel <joel_Schantz at yahoo dot com>]

With respects to Kai (please correct any glaring errors)

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
ll		is working windows script for windows tools
??		script on unix (http://sources.redhat.com/ml/crossgcc/2001-02/msg00141.html)

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)
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, ...
4.	Your rm_crt0.o are not the same! notice the differences for your __vector*_defaults in the two
maps

----
	I have just noticed when linking recently the STARTUP(crt0.o) line in my link.cmd file causes
problems as it is also automatically loaded in the startfile section of specs. this causes the
"multiple definition of `start'" error.

(there used to be a linker option -nostartfiles that disabled this. It seems to be gone now.)
[ what happened to this?? ]

hope this analysis helps, good luck

--	joel



--	just a quick analysis

Mark Palmerino wrote:
> 
> Hi Joel,
> 
> I sent the following to Kai who is providing alot of help.  Given your
> response, which definitely was not a "distraction", I thought the following
> might give you some information that might help you help me...
> 
> Any insights you might have will be greatly appreciated!
> 
> (Note, you will see that I included map files for each compile - hell1 is
> the map that is produced under windows which produces a working S-record
> file and hello.map was produced under unix using libraries brought over from
> Windows.)
> 
> Also I have included the rm_rom.ld file below...
> 
> ----------
> From: Mark Palmerino <mbp@csr-bos.com>
> Date: Tue, 27 Feb 2001 07:30:32 -0500
> To: <karuottu@freenet.hut.fi>
> Subject: Re: Searching for lib...
> 
> Hi Kai,
> 
> You wrote:
> 
> > You must have something in the Windows-hosted tools where the standard
> > C-functions are, a library, separate objects ('.o') etc.  Just toy with
> > the Windows-hosted tools using the '-v' while compiling & linking and try
> > to see what else it uses but the 'rm_rom.ld' and 'rm_crt0.o'...
> >
> 
> Ok, after my last email message, I'm turning my attention to the
> windows-hosted tools.  I am starting with essentially the same program
> (called hell1.c) and it is:
> 
> ------------------------------------
> #include <stdio.h>
> 
> int main(void) {
>   int i;
> 
>   printf("Hello World!\n");
> 
> }
> ------------------------------------
> 
> If I invoke the c compiler as follows:
> 
> cc -v hell1.c
> 
> I get:
> 
> gcc -c -b 68k -mcpu32 -Ic:\xgcc\68k\2_8_1\include hell1.c -v
> Using builtin specs.
> gcc version 2.8.1
>  cpp -lang-c -v -Ic:\xgcc\68k\2_8_1\include -undef -D__GNUC__=2
> -D__GNUC_MINOR__=8 -Dunix -Di386 -DGO32 -DMSDOS -D__unix__ -D__i386__
> -D__GO32__ -D__MSDOS__ -D__unix -D__i386 -D__GO32 -D__MSDOS -Asystem(unix)
> -Asystem(msdos) -Acpu(i386) -Amachine(i386) -Di386 -Asystem(unix)
> -Acpu(i386) -Amachine(i386) -D__i386__ -Asystem(unix) -Acpu(i386)
> -Amachine(i386) hell1.c C:\WINDOWS\TEMP/ccaaaaaa.i
>  GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (68k, Motorola
> syntax)
>  #include "..." search starts here:
>  #include <...> search starts here:
>   c:\xgcc\68k\2_8_1\include
>   End of search list.
>    cc1 C:\WINDOWS\TEMP/ccaaaaaa.i -quiet -dumpbase hell1.c -mcpu32 -version
> -o C:\WINDOWS\TEMP/ccaaaaaa.s
>    GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release) (68k) compiled
> by GNU C
>     version 2.8.1.
>      as -o hell1.o C:\WINDOWS\TEMP/ccaaaaaa.s
> 
> Does this tell you anything?  A couple of things I notice. First, this is
> based on version 2.8.1.  Also, the cc1 command is using the -mcpu32 flag...
> Anything else?
> 
> Compilation of rm_crt0.S produces the same kind of output as follows:
> 
> C:\mrm\hello>gcc -c -b 68k -mcpu32 -Ic:\xgcc\68k\2_8_1\include RM_CRT0.S -v
> Using builtin specs.
> gcc version 2.8.1
>  cpp -lang-asm -v -Ic:\xgcc\68k\2_8_1\include -undef -$ -Dunix -Di386 -DGO32
> -DMSDOS -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__unix -D__i386
> -D__GO32 -D__MSDOS -Asystem(unix) -Asystem(msdos) -Acpu(i386)
> -Amachine(i386) -D__ASSEMBLER__ -Di386 -Asystem(unix) -Acpu(i386)
> -Amachine(i386) -D__i386__ -Asystem(unix) -Acpu(i386) -Amachine(i386)
> RM_CRT0.S C:\WINDOWS\TEMP/ccaaaaaa.s
>  GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (68k, Motorola
> syntax
>  )
>  #include "..." search starts here:
>  #include <...> search starts here:
>   c:\xgcc\68k\2_8_1\include
>   End of search list.
>    as -o RM_CRT0.o C:\WINDOWS\TEMP/ccaaaaaa.s
> 
> Next is the link command, which is invoked with a script called 'll' - here
> is the output:
> 
> C:\mrm\hello>ll hell1 hell1.o
> 
> C:\mrm\hello>ld -s -M -o hell1.cof -Lc:/xgcc/68k/2_8_1/mcpu32
> -Lc:/xgcc/68k/2_8_1 -Lc:/xgcc hell1.o        -T rm_rom.ld > hell1.map
> 
> C:\mrm\hello>68k-objc -O srec hell1.cof hell1.s19
> 
> C:\mrm\hello>copy hell1.s19 hell1.txt
>         1 file(s) copied
> 
> The above is telling me which directories ld is looking in for libraries
> (.../mcpu32 and .../2_8_1), it isn't mentioning the actual .a files it is
> trying to access.
> 
> Could the libraries that it needs be specified in rm_rom.ld? I notice the
> following lines (the entire file is included below for possible reference):
> 
> ---------------- clip ---------------
> 
> STARTUP(rm_crt0.o)
> OUTPUT_ARCH(m68k)
> SEARCH_DIR(.)
> /*
> INPUT(vectors.o)
> */
> /*
> GROUP(-ltrgt -lrom -lc -lgcc)
> */
> GROUP(-lbcc -lc -lgcc -lm)
> 
> ---------------- clip ---------------
> 
> It looks to me like one 'GROUP' line is commented out and the other contains
> the libraries that I have been working with with the exception of libm.a
> (I'm presuming the math library). Am I reading it right?
> 
> Also, commented out 'INPUT(vectors.o)' in addition to the following in the
> comments included in rm_rom.ld make me wonder:
> 
> ------
> 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.
> ------
> 
> I don't see __vector_default defined in the rm_rom.ld file - is this a
> problem or am I "tilting at windmills"?
> 
> BTW, vectors.o does exist in the following directory:
> 
> c:/xgcc/68k/2_8_1/mcpu32
> 
> Is something during the link phase looking for vectors.o and then finding
> it?  Is there a way to get ld to spit out exactly what it is doing or has
> done?  On the other hand, it looks like the .map files contain alot of
> useful information. I will look at them in more detail, but at first glance
> I don't see that any other libraries than those mentioned are being accessed
> (lbcc, lc, lgcc and lm - the latter I will pull over from windows and try a
> recompile, but I don't think that will make a difference...).  Please note
> that the hello.map is what is generated from the ld command that fails with
> the following:
> 
> libc.a(exit.o)(.text+0x52):exit.c: undefined reference to `_exit'
> libc.a(sbrkr.o)(.text+0x12):sbrkr.c: undefined reference to `sbrk'
> libc.a(makebuf.o)(.text+0xdc):makebuf.c: undefined reference to `isatty'
> libc.a(readr.o)(.text+0x1a):readr.c: undefined reference to `read'
> libc.a(lseekr.o)(.text+0x1a):lseekr.c: undefined reference to `lseek'
> libc.a(writer.o)(.text+0x1a):writer.c: undefined reference to `write'
> libc.a(closer.o)(.text+0x12):closer.c: undefined reference to `close'
> libc.a(fstatr.o)(.text+0x16):fstatr.c: undefined reference to `fstat'
> 
> And, there is no reference to 'vectors.o' in either .map file.
> 
> Any suggestions of where to go next?
> 
> Thank you, very much!
> 
> 
> 
> 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