Problems during shifting syscalls from /sys to /libgloss
Joel Sherrill
joel.sherrill@oarcorp.com
Fri Jun 22 16:24:00 GMT 2007
Jeff Johnston wrote:
> Hi Bhushan,
>
> I'm afraid I can't help you much with this particular problem
> remotely. You're going to
> have to do some debugging and find out where it is getting _read from
> and why
> it didn't get your version. If you use nm (for your platform) with
> the -l option, you
> should be able to figure out which file the executable is using for
> _read.
>
> e.g. mn10300-elf-nm -l a.out
Thanks for the -l Jeff. I didn't know that one existed. I always used
ld -Map.
You learn something every day. :-D
--joel
>
> -- Jeff J.
>
> Bhushan Attarde wrote:
>> Hi Jeff,
>>
>> First of all thanks for your reply.
>> I followed your suggestion and the problem of undefined references got
>> solved and the applications are getting compiled successfully.
>>
>> But now I got stuck into another problem........
>>
>> We have our own defined syscall functions(_read, _write) for serial port
>> read/write operations. These functions are implemented in syscalls.c as
>> a source file.
>>
>> But during application compilation libgloss syscalls functions are not
>> getting replaced by our own defined sycalls. This was not a problem when
>> syscalls were in libc/sys/.
>> This can be seen from disassembly listing (lss) files.
>>
>> When sycalls were in libc/sys : ...................
>> .................
>> 00c008d6 <__read>:
>> int _read (int file, char *ptr, int len)
>> {
>> c008d6: 88 10 mov [-r0],r1
>> c008d8: f0 10 mov r1,r0
>> c008da: 26 f0 08 00 sub r0,#0x8
>> c008de: ec f2 push r2
>> c008e0: ec f3 push r3
>> c008e2: c4 81 fe ff mov [r1+#0xfffe],r8
>> c008e6: c4 a1 fc ff mov [r1+#0xfffc],r10
>> c008ea: c4 91 fa ff mov [r1+#0xfffa],r9
>> c008ee: c4 b1 f8 ff mov [r1+#0xfff8],r11
>> *ptr=getkey();
>> c008f2: da c0 28 08 calls #seg:0xc0,#sof:0x828
>> c008f6: d4 31 fc ff mov r3,[r1+#0xfffc]
>> c008fa: d4 21 fa ff mov r2,[r1+#0xfffa]
>> c008fe: dc 43 extp r3,#0x1
>> c00900: b9 82 movb [r2],rl4
>> return (1);
>> c00902: e0 12 mov r2,#0x1
>> }
>> c00904: f0 42 mov r4,r2
>> c00906: fc f3 pop r3
>> c00908: fc f2 pop r2
>> c0090a: 06 f0 08 00 add r0,#0x8
>> c0090e: 98 10 mov r1,[r0+]
>> c00910: db 00 rets
>> ..........................
>>
>>
>>
>> When sycalls are now in /libgloss :
>> ..........................
>> ..........................
>> 00c0e780 <__read>:
>> c0e780: 88 10 mov [-r0],r1
>> c0e782: f0 10 mov r1,r0
>> c0e784: e0 1b mov r11,#0x1
>> c0e786: f0 99 mov r9,r9
>> c0e788: f0 aa mov r10,r10
>> c0e78a: da c0 ac e7 calls #seg:0xc0,#sof:0xe7ac
>> c0e78e: 98 10 mov r1,[r0+]
>> c0e790: db 00 rets
>> .....................
>>
>>
>> So what is the problem ?
>> Did we miss something like macros etc.?
>> What should I need to do?
>>
>> Thanks in advance
>>
>> --Bhushan
>>
>> -----Original Message-----
>> From: Jeff Johnston [mailto:jjohnstn@redhat.com] Sent: Friday, June
>> 15, 2007 9:46 PM
>> To: Bhushan Attarde
>> Cc: newlib@sources.redhat.com; crossgcc@sources.redhat.com
>> Subject: Re: Problems during shifting syscalls from /sys to /libgloss
>>
>> Bhushan Attarde wrote:
>>
>>> Hi,
>>>
>>>
>>> We are working on GNU based tool chain for infineon xc16x
>>> microcontroller.
>>> Currently the syscalls are in /newlib/libc/sys and we are trying to
>>> shift them to /libgloss.
>>>
>>> So after some google search we found some way to do that.......
>>> And done some changes which are as follows:
>>>
>>>
>>> * newlib-1.15.0/configure.in : removed target-libgloss from
>>> noconfigdirs for xc16x-*-*
>>> * configure : regenrate
>>> * newlib-1.15.0/newlib/configure.host: : set sys_dir to empty for
>>> xc16x-*-
>>> And set syscall_dir to xc16x
>>>
>>> * configure : regenerate * newlib/libc/sys/xc16x/ configure.in
>>> : removed
>>> * newlib/libc/sys/xc16x/ configure : removed
>>>
>>> * newlib/libc/sys/xc16x/ crt0.s : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ close.s : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ create.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ getchar1.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ isatty.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ lseek.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ mem-layout : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ misc.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ open.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ putchar.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ puts.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ read.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ sbrk.c: moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ syscalls.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ trap-handle.c : moved to libgloss/xc16x
>>> * newlib/libc/sys/xc16x/ write.c : moved to libgloss/xc16x
>>>
>>> * newlib/libc/sys/xc16x : reomoved
>>>
>>> * libgloss/xc16x/configure.in : new
>>> * libgloss/xc16x/configure : regenerate
>>>
>>>
>>>
>>> With these changes I built the tool chain, it got built without any
>>> error.
>>>
>>> But when I tried to compile one of our sample program I got the
>>> following errors...............
>>>
>>>
>>>
>>>
>> /home/bhushana/XC16X/run/xc16x-elf/lib/gcc/xc16x-elf/4.2.0/../../../../x
>>
>>> c16x-elf/lib/xc16xl/libg.a(lib_a-makebuf.o): In function
>>>
>> `___smakebuf':
>>
>>> makebuf.c:(.text+0x1fb): undefined reference to `_isatty'
>>>
>>> makebuf.c:(.text+0x1fc): undefined reference to `_isatty'
>>>
>>>
>>>
>> /home/bhushana/XC16X/run/xc16x-elf/lib/gcc/xc16x-elf/4.2.0/../../../../x
>>
>>> c16x-elf/lib/xc16xl/libg.a(lib_a-sbrkr.o): In function `__sbrk_r':
>>>
>>> sbrkr.c:(.text+0x1d): undefined reference to `__sbrk'
>>>
>>> sbrkr.c:(.text+0x1e): undefined reference to `__sbrk'
>>>
>>>
>>>
>> /home/bhushana/XC16X/run/xc16x-elf/lib/gcc/xc16x-elf/4.2.0/../../../../x
>>
>>> c16x-elf/lib/xc16xl/libg.a(lib_a-closer.o): In function `__close_r':
>>>
>>> closer.c:(.text+0x1b): undefined reference to `__close'
>>>
>>> closer.c:(.text+0x1c): undefined reference to `__close'
>>>
>>>
>>>
>> /home/bhushana/XC16X/run/xc16x-elf/lib/gcc/xc16x-elf/4.2.0/../../../../x
>>
>>> c16x-elf/lib/xc16xl/libg.a(lib_a-fstatr.o): In function `__fstat_r':
>>>
>>> fstatr.c:(.text+0x25): undefined reference to `__fstat'
>>>
>>> fstatr.c:(.text+0x26): undefined reference to `__fstat'
>>>
>>>
>>>
>> /home/bhushana/XC16X/run/xc16x-elf/lib/gcc/xc16x-elf/4.2.0/../../../../x
>>
>>> c16x-elf/lib/xc16xl/libg.a(lib_a-lseekr.o): In function `__lseek_r':
>>>
>>> lseekr.c:(.text+0x2d): undefined reference to `__lseek'
>>>
>>> lseekr.c:(.text+0x2e): undefined reference to `__lseek'
>>>
>>> collect2: ld returned 1 exit status
>>>
>>> make: *** [Mathtest.out] Error 1
>>>
>>>
>>>
>>> what went wrong ? Or the changes are incomplete and needs to do more?
>>> What should I need to do?
>>>
>>>
>>
>> Hi Bhushan,
>>
>> Don't forget that the compiler needs to be informed of your change as
>>
>> well when it adds library references when linking. If you have
>> introduced a new library, you will have to either refer to it
>> manually on your compile/link command or you will need to modify the
>> compiler so it adds it automatically.
>>
>> A common way of implementing libgloss is to use an ld script. The ld
>>
>> script contains all the information needed to link so all that is needed
>>
>> is to add: -Txxxx.ld to the compile/link command. This is useful in the
>>
>> case of multiple board configurations as you can have yyyy.ld and
>> zzzz.ld, etc... One could modify the compiler to add options to do this
>>
>> automatically on behalf of the end-user (e.g. -mxxxxx translates to
>> -Txxxxx.ld when linking) or if there is only one choice to hardwire
>> the needed reference.
>>
>> Check out libgloss/mn10300/sim.ld for an example of an ld script.
>> Note the GROUP directive to repeatedly search the given libraries.
>>
>> -- Jeff J.
>>
>
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>
--
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc
mailing list