This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

答复: newlib-2.2.0/libgloss/mips/crt0.S:161: undefined reference to `hardware_hazard_hook'


>Zhangwen (Esan) <zwzhangwen.zhang@huawei.com> writes:
>> >It looks like you have not specified any form of linker script and 
>> >MIPS
>> crt0.S in newlib only works in conjunction with a linker script as it 
>> is dependent on external symbols that are not provided by the C 
>> library or ordinary modules:
>> >
>> >1) MIPS uses _start as the entry point not __start
>> >2) The various init hooks are normally defined weak via the linker
>> >  script
>> >
>> >3) The stack must be defined somewhere using the __stack symbol
>> >   which is normally set to a valid address via the linker script.
>> >
>> >See mti32.ld as an example linker script although I doubt it will be
>> suitable for your environment as it is designed around an older boot 
>> monitor. Mti32.ld will however create you an executable that you can 
>> run using the GNUSIM simulator provided with GDB.
>> >
>> >Hope that helps.
>> >
>> >Thanks,
>> >Matthew
>> It's a great help for me and thanks very much. After I rewrote a new 
>> linker script and add the definition of most symbols, there was only 
>> one symbol undefined:
>> newlib-2.2.0/libgloss/mips/crt0.S:195: undefined reference to 
>> `get_mem_info'
>> I found it in the source code:
>> libgloss/mips/jmr3904-io.c:100:get_mem_info (mem) 
>> libgloss/mips/dvemon.c:79:get_mem_info (mem) 
>> libgloss/mips/cfe_mem.c:126:get_mem_info (struct s_mem *meminfo) 
>> libgloss/mips/cygmon.c:78:get_mem_info (mem) Then I search the .c 
>> files in building log, but no the corresponding files. Maybe .c files 
>> can not be compiled in building newlib, so the symbol " get_mem_info " 
>> is undefined when linking.
>> But I have two problems:
>> 1) How can .c file with the definition " get_mem_info " be compiled?
>
>You probably need to provide your own get_mem_info unless one of the existing implementations is suitable for your runtime environment. What gets included in your build depends on the triple you use to configure newlib. See libgloss/mips/configure[.in]. You may want libnullmon.a which has a fairly basic version of get_mem_info.
>
>> 2) How can crt0.o file be linked default when excuting mips-*-ld? Now 
>> I need to add the crt0.o manually.
>
>The crt0.o file is often listed in the linker script using a START(crt0.o) Which means you don't need to list crt0.o on the command line. You do however have to use a linker script always as the default (built-in) link scripts that come with BFD are for GNU/Linux environments and are not suitable for bare metal systems.
>
>> I have no experience on mips compile, so the low problems are more 
>> than others.
>
>I'm sorry to say that for some of these issues you just have to keep working through the issues until you get there. Don't be surprised/afraid if you have to write your own function(s) to make everything work for your board/sim/environment as it is unlikely to be supported with existing code.
>
>Matthew

Greatly! A case can be compiled to binary! I will test the correctness on qemu...
So thanks for a great help.

Cheers,
Zhangwen

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