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]
Other format: [Raw text]

Re: cannot open crt0.o


Hi,

Thanks Doug and Kai for your help.

As per the hint given by Doug, I edited idt.ld linker script itself, and 
commented the line: "STARTUP(crt0.o)"..

But may be editing specs, as suggested by Kai, might be a more appropriate 
way.. So, now I can build the simple 'C' application with MIPS 
cross-compiler..

But it seems that this cross-compiler doesn't support COFF or DWARF debug 
format.

For, COFF (-gcoff), it produces lot of errors like:

/tmp/cchT0rtW.s: Assembler messages:
/tmp/cchT0rtW.s:7: Error: unknown pseudo-op: `.def'
/tmp/cchT0rtW.s:7: Error: unknown pseudo-op: `.scl'
/tmp/cchT0rtW.s:7: Error: unknown pseudo-op: `.etype'
/tmp/cchT0rtW.s:7: Error: unknown pseudo-op: `.endef'
/tmp/cchT0rtW.s:8: Error: unknown pseudo-op: `.def'
/tmp/cchT0rtW.s:8: Error: unknown pseudo-op: `.scl'
....
....
....
....
....

, where as for DWARF (-gdwarf), it says:

cc1: warning: `dwarf': unknown or unsupported -g option

adding "--enable-dwarf" to configure script of gcc, also doesn't help.. 
anyway, first of all I am not sure whether "--enable-dwarf" is a valid 
option or not.

Regards,
Abhijit.

On Fri, 11 Jul 2003, Kai Ruottu wrote:

> You wrote:
> 
> > I have built these tools for mips-elf target.
> 
>  Just look at the name 'elf'... For me it always gives names like 'Galadriel',
> 'Tinuviel' etc. from the Tolkien book. Whether elves are real targets at all,
> is the important question ;-) For me they aren't meanwhile 'linux', 'aix', 'svr4.2'
> etc. are. Some elves like the Japanese ones have aliases, monitors like 'CMON' and
> 'HMS' in the Hitachi ones, but maybe best aliases are the 'Angel' and 'Demon' in
> ARM...
> 
>  One must have some real target like an opsys or a target board with firmware on
> it, or self-implented support in the C library etc., before creating apps for it
> will be possible. Newlib supports some MIPS-based targets boards, but GCC has not
> any of these as the default alias for the 'mips-elf' target. The weird libs produced
> in 'libgloss/mips' and the '.ld' files most probably now in your 'lib' now, provide
> this support...  So you must edit your 'specs', please see with 'mips-elf-gcc -v'
> where it is now, and then edit the following rows to be exactly like:
> 
> ------------------------------------ clip ---------------------------------------
> *endfile:
> crtend%O%s crtn%O%s -T idt.ld%s
> 
> *link:
> %(endian_spec) %{G*} %{mips1} %{mips2} %{mips3} %{mips4} %{mips32} %{mips64} %{bestGnum} %{shared} %{non_shared}
> 
> *lib:
> 
> 
> *libgcc:
> 
> 
> *startfile:
> crti%O%s crtbegin%O%s
> 
> *switches_need_spaces:
> 
> ------------------------------------ clip ---------------------------------------
> 
> ie. edit the 'endfile' and 'startfile' and empty the 'lib' and 'libgcc' totally.
> The linker script 'idt.ld' will take care of the main startup name (crt0.o) and
> the library names among many other things related to the IDT-board. Of course
> you can try other '.ld' files and look what they are for, I used the IDT-board
> as my default, and executables made for it seem to run ok in the MIPS-simulator
> coming with GDB. So building still GDB can be one more homework to you...
> 
>  Be careful with the 'specs' file, the format really MUST be as it is, only one
> row for the spec-value, be it short or very long and an empty row between the
> value (can be an empty row too) and the next spec-name.
> 
> > But now, when I try to compile a simple 'C' source code, it fails to do so 
> > with following messages:
> > 
> > crt0.S:81: undefined reference to `hardware_hazard_hook'
> > crt0.S:147: undefined reference to `get_mem_info'
> > crt0.S:151: undefined reference to `__stack'
> > crt0.S:193: undefined reference to `software_init_hook'
> > crt0.S:200: undefined reference to `atexit'
> > crt0.S:221: undefined reference to `exit'
> > crt0.o: In function `_exit'
> > crt0.S:259: undefined reference to `hardware_exit_hook'
> 
>  The 'idt.ld' and the support libs provide these things :
> 
> ------------------------------------ clip ---------------------------------------
> /* The following TEXT start address leaves space for the monitor
>    workspace. i.e. the NEC VR4300 (IDT) first free address is actually
>    0xa001af20. */
> 
> ENTRY(_start)
> STARTUP(crt0.o)         <--------
> OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-littlemips")
> GROUP(-lc -lidt -lgcc)  <---------
> SEARCH_DIR(.)
> __DYNAMIC  =  0;
> 
> /*
>  * Allocate the stack to be at the top of memory, since the stack
>  * grows down
>  */
> PROVIDE (__stack = 0);
> /* PROVIDE (__global = 0); */
> 
> /*
>  * 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 multiple object file
>  * formats, as some prepend an underscore.
>  */
> PROVIDE (hardware_exit_hook = 0);    <----------
> PROVIDE (hardware_hazard_hook = 0);
> PROVIDE (hardware_init_hook = 0);
> PROVIDE (software_init_hook = 0);
> 
> SECTIONS
> {	
> ------------------------------------ clip ---------------------------------------
> 
>  Using a GCC for embedded targets is somehow different from using one for an
> opsys, or what do you think?  Ok, basically the question is about finding the
> right Lego-pieces among the existing stuff and putting them together...
> 
>  BTW, if you need any simulated hardware, not only the CPU+monitor firmware,
> then the 'mipstx39-elf' could be better, the GDB/simulator for it should take
> all that tx3904-stuff with the simulator, like:
> 
> ------------------------------------ clip ---------------------------------------
> /* DEVICE
> 
>    
>    tx3904sio - tx3904 serial I/O
> 
>    
>    DESCRIPTION
> 
>    
>    Implements one tx3904 serial I/O controller described in the tx3904
>    user guide.  Three instances are required for SIO0 and SIO1 within
>    the tx3904, at different base addresses.
> 
>    Both internal and system clocks are synthesized as divided versions
>    of the simulator clock.
>    
>    There is no support for:
>     - CTS/RTS flow control
>     - baud rate emulation - use infinite speed instead
>     - general frame format - use 8N1
>     - multi-controller system
>     - DMA - use interrupt-driven or polled-I/O instead
> ------------------------------------ clip ---------------------------------------
> 
>  Please see the 'sim/mips/dv-tx3904*' stuff in the GDB sources... Maybe the
> 'mips-elf' included this too but I'm not sure. There are also other special
> MIPS-targets like 'mips64orionel-elf' which can give something the generic
> targets don't give...
> 
> Cheers, Kai
> 
> PS. When reading later messages, I saw you becoming aware of this 'elves'
> problem and Doug Evans giving right clues... Maybe leaving the 'T idt.ld'
> away from the 'endfile' would be better and allow you to test the different
> scripts... Anyway taking the 'crt0.o' and the library names away from the
> 'specs' must be done as your problems showed...
> 

-- 
--------------------------------------------------------------------------
Abhijit Deshpande                       |Tel: +91-80-5234641/42 (Ext. 209)
SoftJin Infotech Pvt. Ltd.,             |Email: abhijit@softjin.com
227/70/A, Sigma Arcade I,               |Web: http://www.softjin.com
Marathahalli, Airport Road,             |Fax: +91-80-5234643
Bangalore - 560 037 India.              |
--------------------------------------------------------------------------
SOFTJIN BUSINESS DISCLAIMER

This e-mail message and any files transmitted with it are intended
solely for the use of individual or entity to which they are addressed.
It may contain confidential, proprietary or legally privileged
information. If you are not the intended recipient please be advised
that you have received this message in error and any use is strictly
prohibited. Please immediately delete it and all copies from your
system, destroy any hard copies of it and notify the sender by return
mail. You must not, directly or indirectly, use, disclose, distribute,
print, or copy any part of this message if you are not the intended
recipient.
--------------------------------------------------------------------------


Attachment: VirusWall_Message.txt
Description: Text document

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]