Problems during shifting syscalls from /sys to /libgloss

Fri Jun 22 16:11:00 GMT 2007

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

-- 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