inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory
Locked
 
|
james osburn |
inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory
|
I am getting the following error listed in the subject line and I looked up the error in the mail list archive and did find it mentioned in a previous post. I then followed the fix, which was to make sure that the paths to the compiler were set correctly.
I removed the code source install cleaned up the path and used an un-installer to remove any previous installs. Then ran the following but the error persists. C:\Users\josburn\Documents\programming\elua>scons target=lua board=ek-lm3s9b92 c pumode=thumb toolchain=codesourcery scons: Reading SConscript files ... WARNING: unable to determine version from repository ********************************* Compiling eLua ... CPU: LM3S9B92 Board: EK-LM3S9B92 Platform: lm3s Allocator: newlib Boot Mode: standard Target: lua Toolchain: codesourcery ROMFS mode: verbatim Version: unknown ********************************* Building ROM File System... Done, total size is 1 bytes scons: done reading SConscript files. scons: Building targets ... arm-none-eabi-gcc -o src\main.o -c -mcpu=cortex-m3 -mthumb -mlittle-endian -Os - fomit-frame-pointer -ffunction-sections -fdata-sections -fno-strict-aliasing -Wa ll -DELUA_BOARD=EK-LM3S9B92 -DELUA_PLATFORM=LM3S -D__BUFSIZ__=128 -DELUA_CPU=LM3 S9B92 -DELUA_CPU_LM3S9B92 -DELUA_BOARD_EKLM3S9B92 -DELUA_PLATFORM_LM3S -DLUA_PAC K_VALUE -DELUA_ENDIAN_LITTLE -DLUA_OPTIMIZE_MEMORY=2 -DFORLM3S9B92 -Dgcc -DCORTE X_M3 -Iinc -Iinc\newlib -Iinc\remotefs -Isrc\platform -Isrc\lua -Isrc\modules -I src\platform\lm3s -Isrc\uip -Isrc\fatfs -Isrc\platform\lm3s\inc -Isrc\platform\l m3s\driverlib -Isrc\platform\lm3s\usblib -Isrc\platform\lm3s\usblib\device src\m ain.c In file included from src\main.c:6:0: inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory compilation terminated. scons: *** [src\main.o] Error 1 scons: building terminated because of errors. Here is the system setup for my pc. My path is as follows: C:\Users\josburn\Documents\programming\elua>echo %path% C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\Wind owsPowerShell\v1.0\;C:\Program Files\TortoiseSVN\bin;c:\Program Files (x86)\popl er;C:\Program Files\IVI Foundation\VISA\Win64\Bin\;C:\Program Files (x86)\IVI Fo undation\VISA\WinNT\Bin\;C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Bin;C: \Python27;C:\Python27\Scripts;c:\Program Files (x86)\Microsoft SQL Server\100\To ols\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files \Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\CodeSourcery\Sourcery _CodeBench_for_ARM_EABI\bin;; The version information for the compiler is: C:\Users\josburn\Documents\programming\elua>arm-none-eabi-gcc --version arm-none-eabi-gcc (Sourcery CodeBench 2012.03-28) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. james _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Karoly Molnar |
Re: inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory
|
|
I just had the same issue couple of hours ago.
I managed to push the compilation forward by hacking the code by replacing <reent.h> to <sys/reent.h> in all relevant locations, but finally ended up in other missing macros. I have a full Codesourcery license, but it appears to have different content than the Lite edition. I have then just installed a fresh Lite to a different folder and reverted my previous hacks. I have set the Lite edition ahead of the full install in my windows PATH and now it builds correctly. Date: Sun, 22 Jul 2012 15:20:07 -0500 From: [hidden email] To: [hidden email] Subject: [eLua-dev] inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory I am getting the following error listed in the subject line and I looked up the error in the mail list archive and did find it mentioned in a previous post. I then followed the fix, which was to make sure that the paths to the compiler were set correctly. I removed the code source install cleaned up the path and used an un-installer to remove any previous installs. Then ran the following but the error persists. C:\Users\josburn\Documents\programming\elua>scons target=lua board=ek-lm3s9b92 c pumode=thumb toolchain=codesourcery scons: Reading SConscript files ... WARNING: unable to determine version from repository ********************************* Compiling eLua ... CPU: LM3S9B92 Board: EK-LM3S9B92 Platform: lm3s Allocator: newlib Boot Mode: standard Target: lua Toolchain: codesourcery ROMFS mode: verbatim Version: unknown ********************************* Building ROM File System... Done, total size is 1 bytes scons: done reading SConscript files. scons: Building targets ... arm-none-eabi-gcc -o src\main.o -c -mcpu=cortex-m3 -mthumb -mlittle-endian -Os - fomit-frame-pointer -ffunction-sections -fdata-sections -fno-strict-aliasing -Wa ll -DELUA_BOARD=EK-LM3S9B92 -DELUA_PLATFORM=LM3S -D__BUFSIZ__=128 -DELUA_CPU=LM3 S9B92 -DELUA_CPU_LM3S9B92 -DELUA_BOARD_EKLM3S9B92 -DELUA_PLATFORM_LM3S -DLUA_PAC K_VALUE -DELUA_ENDIAN_LITTLE -DLUA_OPTIMIZE_MEMORY=2 -DFORLM3S9B92 -Dgcc -DCORTE X_M3 -Iinc -Iinc\newlib -Iinc\remotefs -Isrc\platform -Isrc\lua -Isrc\modules -I src\platform\lm3s -Isrc\uip -Isrc\fatfs -Isrc\platform\lm3s\inc -Isrc\platform\l m3s\driverlib -Isrc\platform\lm3s\usblib -Isrc\platform\lm3s\usblib\device src\m ain.c In file included from src\main.c:6:0: inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory compilation terminated. scons: *** [src\main.o] Error 1 scons: building terminated because of errors. Here is the system setup for my pc. My path is as follows: C:\Users\josburn\Documents\programming\elua>echo %path% C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\Wind owsPowerShell\v1.0\;C:\Program Files\TortoiseSVN\bin;c:\Program Files (x86)\popl er;C:\Program Files\IVI Foundation\VISA\Win64\Bin\;C:\Program Files (x86)\IVI Fo undation\VISA\WinNT\Bin\;C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Bin;C: \Python27;C:\Python27\Scripts;c:\Program Files (x86)\Microsoft SQL Server\100\To ols\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files \Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\CodeSourcery\Sourcery _CodeBench_for_ARM_EABI\bin;; The version information for the compiler is: C:\Users\josburn\Documents\programming\elua>arm-none-eabi-gcc --version arm-none-eabi-gcc (Sourcery CodeBench 2012.03-28) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. james _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
james osburn |
Re: inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory
|
|
Are you building on windows as well? also I have the 30 day version of code sourcery not the light version.
James On Sun, Jul 22, 2012 at 4:08 PM, Karoly Molnar <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Karoly Molnar |
Re: inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory
|
|
Yes, on windows. Seems it works without hacking with the Lite edition only.
Karoly Date: Sun, 22 Jul 2012 16:17:26 -0500 From: [hidden email] To: [hidden email] Subject: Re: [eLua-dev] inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory Are you building on windows as well? also I have the 30 day version of code sourcery not the light version. James On Sun, Jul 22, 2012 at 4:08 PM, Karoly Molnar <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
james osburn |
Re: inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory
|
|
I am going to use the lite edition :
Sourcery CodeBench Lite 2012.03-56 for ARM EABIand make sure its path is in the front of the path.actually my only reason for building elua so include scripts as part of the binary. James On Sun, Jul 22, 2012 at 4:22 PM, Karoly Molnar <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
james osburn |
Re: inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory
|
|
using code soucery lite and removing the other path elements pointing to the 30 day install addressed the issue.
james On Sun, Jul 22, 2012 at 4:26 PM, james osburn <[hidden email]> wrote: I am going to use the lite edition : _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Karoly Molnar |
lualong option and codesourcery
|
|
Hello, I have tried to rebuild the eLua MBED target with codesourcery with the lualong option. The code is working and the code size has been somewhat reduced but it was still fairly big even after turning of all terminal, shell, rpc related options (practically I have commented out all optional macros in the platform_conf.h). Then I have checked the elf file with objdump and realized that it is still using software floating point libraries on some parts of the code, which I did not need in the lualong build. Further investigation has lead to that it is using a floating point version of sprintf(). May I assume that I shall use a special stdlib or newlib that is build without floating point support? Can someone help me with some instructions to rebuild it in the CortexM3/Codesourcery environment? Thanks Karoly _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: lualong option and codesourcery
|
|
On 23 July 2012 18:26, Karoly Molnar <[hidden email]> wrote:
> I have tried to rebuild the eLua MBED target with codesourcery with the > lualong option. The code is working and the code size has been somewhat > reduced but it was still fairly big even after turning of all terminal, > shell, rpc related options (practically I have commented out all optional > macros in the platform_conf.h). > > Then I have checked the elf file with objdump and realized that it is still > using software floating point libraries on some parts of the code, which I > did not need in the lualong build. Further investigation has lead to that it > is using a floating point version of sprintf(). > May I assume that I shall use a special stdlib or newlib that is build > without floating point support? Can someone help me with some instructions > to rebuild it in the CortexM3/Codesourcery environment? Hi Karolv a lualong build should contain no floating point - there are a couple of #defines in src/newlib/stubs.c to link to the integer versions of the printf functions. Maybe you can in investigate those. If you need a smaller build, check the mizar32 branch which contains a bunch of hacks to reduce code size to 120K on AVR32 while retaining all of the essential functionality of eLua. Cheers M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Karoly Molnar
Hi,
On Mon, Jul 23, 2012 at 7:26 PM, Karoly Molnar <[hidden email]> wrote: > > Hello, > > I have tried to rebuild the eLua MBED target with codesourcery with the > lualong option. The code is working and the code size has been somewhat > reduced but it was still fairly big even after turning of all terminal, > shell, rpc related options (practically I have commented out all optional > macros in the platform_conf.h). > > Then I have checked the elf file with objdump and realized that it is still > using software floating point libraries on some parts of the code, which I > did not need in the lualong build. Further investigation has lead to that it > is using a floating point version of sprintf(). > May I assume that I shall use a special stdlib or newlib that is build > without floating point support? Can someone help me with some instructions > to rebuild it in the CortexM3/Codesourcery environment? We have this little piece of code in src/newlib/stubs.c: // If LUA_NUMBER_INTEGRAL is defined, "redirect" printf/scanf calls to their // integer counterparts #ifdef LUA_NUMBER_INTEGRAL int _vfprintf_r( struct _reent *r, FILE *stream, const char *format, va_list ap ) { return _vfiprintf_r( r, stream, format, ap ); } extern int __svfiscanf_r(struct _reent *,FILE *, _CONST char *,va_list); int __svfscanf_r( struct _reent *r, FILE *stream, const char *format, va_list ap ) { return __svfiscanf_r( r, stream, format, ap ); } #endif // #ifdef LUA_NUMBER_INTEGRAL What it does is link against special versions of the printf/scanf functions (vfiprintf/vfiscanf) that have no floating point support whatsoever. This used to work in the past and showed a clear improvement in the image size. If it doesn't work anymore, a couple of things come to mind: - a broken Newlib build that doesn't ignore floating point operations for vfiprintf/vfiscanf as it should - FP functions are pulled in by other part(s) of the code However, this seems to work on my fairly new master: ~/work/elua/elua [master] $ lua build_elua.lua board=et-stm32 prog Generating binary image elua_lua_stm32f103re.bin... text data bss dec hex filename 227368 1536 1988 230892 385ec elua_lua_stm32f103re.elf ~/work/elua/elua [master] $ lua build_elua.lua board=et-stm32 prog target=lualong [TARGET] elua_lualong_stm32f103re.bin Generating binary image elua_lualong_stm32f103re.bin... text data bss dec hex filename 190744 1532 1988 194264 2f6d8 elua_lualong_stm32f103re.elf The difference most likely indicates that the FP functions are not pulled in, so I'm guessing there's a problem with your particular toolchain (I'm using arm-none-eabi-gcc (Sourcery G++ Lite 2011.03-42) 4.5.2 in Linux). One more question: how did you find out that the floating point libraries are pulled in the binary? What symbol(s) gave it away? Thanks, Bogdan > > Thanks > Karoly > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Karoly Molnar |
Re: lualong option and codesourcery
|
|
Thanks for the hints. I have no idea on how it was working in the past or how it is supposed to be using because I have just started playing with eLua two days ago. So if I am asking newbie questions it is just because I am that :)
I have done two things to reveal floating point in the lualong build: First, simply without knowing what I am looking for exactly, checked the objdump -x and -d of the elf file and was looking for individual functions that were bigger than 0x100, especially that were library functionsn starting with __ . Then I have realized that there are a number of __<operator>df3 calls and functions in the binary. These are the double precision software floating point library calls. As much as I see they are only used by an sprintf call that is called from a function "worker" that I was unable to trace further, seems not to be part of eLua so I believe it is the part of the libc delivered with codesourcery. 00018118 <worker>: 18118: e92d 43f0 stmdb sp!, {r4, r5, r6, r7, r8, r9, lr} 1811c: b085 sub sp, #20 .. skip 1813a: 4631 mov r1, r6 1813c: 463b mov r3, r7 1813e: f2c0 0202 movt r2, #2 18142: 4620 mov r0, r4 18144: e88d 4300 stmia.w sp, {r8, r9, lr} ----> here 18148: f7fc fb6e bl 14828 <_sprintf_r> 1814c: 2200 movs r2, #0 I am using the latest sourcery release that is 2012.3. Do you see the same in the objdump when building with an older codesourcery? Thanks Karoly > From: [hidden email] > Date: Mon, 23 Jul 2012 21:10:33 +0300 > To: [hidden email] > Subject: Re: [eLua-dev] lualong option and codesourcery > > Hi, > > On Mon, Jul 23, 2012 at 7:26 PM, Karoly Molnar <[hidden email]> wrote: > > > > Hello, > > > > I have tried to rebuild the eLua MBED target with codesourcery with the > > lualong option. The code is working and the code size has been somewhat > > reduced but it was still fairly big even after turning of all terminal, > > shell, rpc related options (practically I have commented out all optional > > macros in the platform_conf.h). > > > > Then I have checked the elf file with objdump and realized that it is still > > using software floating point libraries on some parts of the code, which I > > did not need in the lualong build. Further investigation has lead to that it > > is using a floating point version of sprintf(). > > May I assume that I shall use a special stdlib or newlib that is build > > without floating point support? Can someone help me with some instructions > > to rebuild it in the CortexM3/Codesourcery environment? > > We have this little piece of code in src/newlib/stubs.c: > > // If LUA_NUMBER_INTEGRAL is defined, "redirect" printf/scanf calls to their > // integer counterparts > #ifdef LUA_NUMBER_INTEGRAL > int _vfprintf_r( struct _reent *r, FILE *stream, const char *format, > va_list ap ) > { > return _vfiprintf_r( r, stream, format, ap ); > } > > extern int __svfiscanf_r(struct _reent *,FILE *, _CONST char *,va_list); > int __svfscanf_r( struct _reent *r, FILE *stream, const char *format, > va_list ap ) > { > return __svfiscanf_r( r, stream, format, ap ); > } > #endif // #ifdef LUA_NUMBER_INTEGRAL > > What it does is link against special versions of the printf/scanf > functions (vfiprintf/vfiscanf) that have no floating point support > whatsoever. This used to work in the past and showed a clear > improvement in the image size. If it doesn't work anymore, a couple of > things come to mind: > > - a broken Newlib build that doesn't ignore floating point operations > for vfiprintf/vfiscanf as it should > - FP functions are pulled in by other part(s) of the code > > However, this seems to work on my fairly new master: > > ~/work/elua/elua [master] $ lua build_elua.lua board=et-stm32 prog > Generating binary image elua_lua_stm32f103re.bin... > text data bss dec hex filename > 227368 1536 1988 230892 385ec elua_lua_stm32f103re.elf > ~/work/elua/elua [master] $ lua build_elua.lua board=et-stm32 prog > target=lualong > [TARGET] elua_lualong_stm32f103re.bin > Generating binary image elua_lualong_stm32f103re.bin... > text data bss dec hex filename > 190744 1532 1988 194264 2f6d8 elua_lualong_stm32f103re.elf > > The difference most likely indicates that the FP functions are not > pulled in, so I'm guessing there's a problem with your particular > toolchain (I'm using arm-none-eabi-gcc (Sourcery G++ Lite 2011.03-42) > 4.5.2 in Linux). > One more question: how did you find out that the floating point > libraries are pulled in the binary? What symbol(s) gave it away? > > Thanks, > Bogdan > > > > > Thanks > > Karoly > > > > > > _______________________________________________ > > eLua-dev mailing list > > [hidden email] > > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Jul 23, 2012 at 9:55 PM, Karoly Molnar <[hidden email]> wrote:
> Thanks for the hints. I have no idea on how it was working in the past or > how it is supposed to be using because I have just started playing with eLua > two days ago. So if I am asking newbie questions it is just because I am > that :) Nope, no newbie questions. There's definitely something going on here (see below). > I have done two things to reveal floating point in the lualong build: > First, simply without knowing what I am looking for exactly, checked the > objdump -x and -d of the elf file and was looking for individual functions > that were bigger than 0x100, especially that were library functionsn > starting with __ . > Then I have realized that there are a number of __<operator>df3 calls and > functions in the binary. These are the double precision software floating > point library calls. As much as I see they are only used by an sprintf call > that is called from a function "worker" that I was unable to trace further, > seems not to be part of eLua so I believe it is the part of the libc > delivered with codesourcery. > > 00018118 <worker>: > 18118: e92d 43f0 stmdb sp!, {r4, r5, r6, r7, r8, r9, lr} > 1811c: b085 sub sp, #20 > .. skip > 1813a: 4631 mov r1, r6 > 1813c: 463b mov r3, r7 > 1813e: f2c0 0202 movt r2, #2 > 18142: 4620 mov r0, r4 > 18144: e88d 4300 stmia.w sp, {r8, r9, lr} > ----> here 18148: f7fc fb6e bl 14828 <_sprintf_r> > 1814c: 2200 movs r2, #0 > > I am using the latest sourcery release that is 2012.3. > > Do you see the same in the objdump when building with an older codesourcery? I can't find any worker function in my disassembled code, but unfortunately I am able to find __adddf3 and similar calls. I looked at the code a bit and understood why this happens.The trouble is that the newlib implementation changed and the "redirects" that I added in stubs.c (the fragment of code that I sent in my previous e-mail) don't do their job properly anymore. I was able to get rid of all the FP calls by adding two more functions to that particular fragment of code, as below: // If LUA_NUMBER_INTEGRAL is defined, "redirect" printf/scanf calls to their // integer counterparts #ifdef LUA_NUMBER_INTEGRAL int _vfprintf_r( struct _reent *r, FILE *stream, const char *format, va_list ap ) { return _vfiprintf_r( r, stream, format, ap ); } extern int _svfiprintf_r( struct _reent *r, FILE *stream, const char *format, va_list ap ); int _svfprintf_r( struct _reent *r, FILE *stream, const char *format, va_list ap ) { return _svfiprintf_r( r, stream, format, ap ); } extern int __svfiscanf_r(struct _reent *,FILE *, _CONST char *,va_list); int __svfscanf_r( struct _reent *r, FILE *stream, const char *format, va_list ap ) { return __svfiscanf_r( r, stream, format, ap ); } extern int __ssvfiscanf_r(struct _reent *,FILE *, _CONST char *,va_list); int __ssvfscanf_r( struct _reent *r, FILE *stream, const char *format, va_list ap ) { return __ssvfiscanf_r( r, stream, format, ap ); } #endif // #ifdef LUA_NUMBER_INTEGRAL The size of the firmware image is now 164744 and there are no more *df3 calls, which is a good thing. This is a bit of "cat and mouse" game between us and the Newlib source code, which I don't particularly enjoy, but there's not much we can do at the moment. Thanks for the report. Good catch. Best, Bogdan > > Thanks > Karoly > > >> From: [hidden email] >> Date: Mon, 23 Jul 2012 21:10:33 +0300 >> To: [hidden email] >> Subject: Re: [eLua-dev] lualong option and codesourcery > >> >> Hi, >> >> On Mon, Jul 23, 2012 at 7:26 PM, Karoly Molnar <[hidden email]> >> wrote: >> > >> > Hello, >> > >> > I have tried to rebuild the eLua MBED target with codesourcery with the >> > lualong option. The code is working and the code size has been somewhat >> > reduced but it was still fairly big even after turning of all terminal, >> > shell, rpc related options (practically I have commented out all >> > optional >> > macros in the platform_conf.h). >> > >> > Then I have checked the elf file with objdump and realized that it is >> > still >> > using software floating point libraries on some parts of the code, which >> > I >> > did not need in the lualong build. Further investigation has lead to >> > that it >> > is using a floating point version of sprintf(). >> > May I assume that I shall use a special stdlib or newlib that is build >> > without floating point support? Can someone help me with some >> > instructions >> > to rebuild it in the CortexM3/Codesourcery environment? >> >> We have this little piece of code in src/newlib/stubs.c: >> >> // If LUA_NUMBER_INTEGRAL is defined, "redirect" printf/scanf calls to >> their >> // integer counterparts >> #ifdef LUA_NUMBER_INTEGRAL >> int _vfprintf_r( struct _reent *r, FILE *stream, const char *format, >> va_list ap ) >> { >> return _vfiprintf_r( r, stream, format, ap ); >> } >> >> extern int __svfiscanf_r(struct _reent *,FILE *, _CONST char *,va_list); >> int __svfscanf_r( struct _reent *r, FILE *stream, const char *format, >> va_list ap ) >> { >> return __svfiscanf_r( r, stream, format, ap ); >> } >> #endif // #ifdef LUA_NUMBER_INTEGRAL >> >> What it does is link against special versions of the printf/scanf >> functions (vfiprintf/vfiscanf) that have no floating point support >> whatsoever. This used to work in the past and showed a clear >> improvement in the image size. If it doesn't work anymore, a couple of >> things come to mind: >> >> - a broken Newlib build that doesn't ignore floating point operations >> for vfiprintf/vfiscanf as it should >> - FP functions are pulled in by other part(s) of the code >> >> However, this seems to work on my fairly new master: >> >> ~/work/elua/elua [master] $ lua build_elua.lua board=et-stm32 prog >> Generating binary image elua_lua_stm32f103re.bin... >> text data bss dec hex filename >> 227368 1536 1988 230892 385ec elua_lua_stm32f103re.elf >> ~/work/elua/elua [master] $ lua build_elua.lua board=et-stm32 prog >> target=lualong >> [TARGET] elua_lualong_stm32f103re.bin >> Generating binary image elua_lualong_stm32f103re.bin... >> text data bss dec hex filename >> 190744 1532 1988 194264 2f6d8 elua_lualong_stm32f103re.elf >> >> The difference most likely indicates that the FP functions are not >> pulled in, so I'm guessing there's a problem with your particular >> toolchain (I'm using arm-none-eabi-gcc (Sourcery G++ Lite 2011.03-42) >> 4.5.2 in Linux). >> One more question: how did you find out that the floating point >> libraries are pulled in the binary? What symbol(s) gave it away? >> >> Thanks, >> Bogdan >> >> > >> > Thanks >> > Karoly >> > >> > >> > _______________________________________________ >> > eLua-dev mailing list >> > [hidden email] >> > https://lists.berlios.de/mailman/listinfo/elua-dev >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Karoly Molnar |
Re: lualong option and codesourcery
|
|
Hi Bogdan,
Thanks for the quick help! I have applied your patch and can confirm that the df3 calls have disappeared from my build, too (gain is about 20Kbytes). Regards Karoly > From: [hidden email] > Date: Tue, 24 Jul 2012 00:16:15 +0300 > To: [hidden email] > Subject: Re: [eLua-dev] lualong option and codesourcery > > On Mon, Jul 23, 2012 at 9:55 PM, Karoly Molnar <[hidden email]> wrote: > > Thanks for the hints. I have no idea on how it was working in the past or > > how it is supposed to be using because I have just started playing with eLua > > two days ago. So if I am asking newbie questions it is just because I am > > that :) > > Nope, no newbie questions. There's definitely something going on here > (see below). > > > I have done two things to reveal floating point in the lualong build: > > First, simply without knowing what I am looking for exactly, checked the > > objdump -x and -d of the elf file and was looking for individual functions > > that were bigger than 0x100, especially that were library functionsn > > starting with __ . > > Then I have realized that there are a number of __<operator>df3 calls and > > functions in the binary. These are the double precision software floating > > point library calls. As much as I see they are only used by an sprintf call > > that is called from a function "worker" that I was unable to trace further, > > seems not to be part of eLua so I believe it is the part of the libc > > delivered with codesourcery. > > > > 00018118 <worker>: > > 18118: e92d 43f0 stmdb sp!, {r4, r5, r6, r7, r8, r9, lr} > > 1811c: b085 sub sp, #20 > > .. skip > > 1813a: 4631 mov r1, r6 > > 1813c: 463b mov r3, r7 > > 1813e: f2c0 0202 movt r2, #2 > > 18142: 4620 mov r0, r4 > > 18144: e88d 4300 stmia.w sp, {r8, r9, lr} > > ----> here 18148: f7fc fb6e bl 14828 <_sprintf_r> > > 1814c: 2200 movs r2, #0 > > > > I am using the latest sourcery release that is 2012.3. > > > > Do you see the same in the objdump when building with an older codesourcery? > > I can't find any worker function in my disassembled code, but > unfortunately I am able to find __adddf3 and similar calls. I looked > at the code a bit and understood why this happens.The trouble is that > the newlib implementation changed and the "redirects" that I added in > stubs.c (the fragment of code that I sent in my previous e-mail) don't > do their job properly anymore. I was able to get rid of all the FP > calls by adding two more functions to that particular fragment of > code, as below: > > // If LUA_NUMBER_INTEGRAL is defined, "redirect" printf/scanf calls to their > // integer counterparts > #ifdef LUA_NUMBER_INTEGRAL > int _vfprintf_r( struct _reent *r, FILE *stream, const char *format, > va_list ap ) > { > return _vfiprintf_r( r, stream, format, ap ); > } > > extern int _svfiprintf_r( struct _reent *r, FILE *stream, const char > *format, va_list ap ); > int _svfprintf_r( struct _reent *r, FILE *stream, const char *format, > va_list ap ) > { > return _svfiprintf_r( r, stream, format, ap ); > } > > extern int __svfiscanf_r(struct _reent *,FILE *, _CONST char *,va_list); > int __svfscanf_r( struct _reent *r, FILE *stream, const char *format, > va_list ap ) > { > return __svfiscanf_r( r, stream, format, ap ); > } > > extern int __ssvfiscanf_r(struct _reent *,FILE *, _CONST char *,va_list); > int __ssvfscanf_r( struct _reent *r, FILE *stream, const char *format, > va_list ap ) > { > return __ssvfiscanf_r( r, stream, format, ap ); > } > > #endif // #ifdef LUA_NUMBER_INTEGRAL > > The size of the firmware image is now 164744 and there are no more > *df3 calls, which is a good thing. This is a bit of "cat and mouse" > game between us and the Newlib source code, which I don't particularly > enjoy, but there's not much we can do at the moment. > Thanks for the report. Good catch. > > Best, > Bogdan > > > > > Thanks > > Karoly > > > > > >> From: [hidden email] > >> Date: Mon, 23 Jul 2012 21:10:33 +0300 > >> To: [hidden email] > >> Subject: Re: [eLua-dev] lualong option and codesourcery > > > >> > >> Hi, > >> > >> On Mon, Jul 23, 2012 at 7:26 PM, Karoly Molnar <[hidden email]> > >> wrote: > >> > > >> > Hello, > >> > > >> > I have tried to rebuild the eLua MBED target with codesourcery with the > >> > lualong option. The code is working and the code size has been somewhat > >> > reduced but it was still fairly big even after turning of all terminal, > >> > shell, rpc related options (practically I have commented out all > >> > optional > >> > macros in the platform_conf.h). > >> > > >> > Then I have checked the elf file with objdump and realized that it is > >> > still > >> > using software floating point libraries on some parts of the code, which > >> > I > >> > did not need in the lualong build. Further investigation has lead to > >> > that it > >> > is using a floating point version of sprintf(). > >> > May I assume that I shall use a special stdlib or newlib that is build > >> > without floating point support? Can someone help me with some > >> > instructions > >> > to rebuild it in the CortexM3/Codesourcery environment? > >> > >> We have this little piece of code in src/newlib/stubs.c: > >> > >> // If LUA_NUMBER_INTEGRAL is defined, "redirect" printf/scanf calls to > >> their > >> // integer counterparts > >> #ifdef LUA_NUMBER_INTEGRAL > >> int _vfprintf_r( struct _reent *r, FILE *stream, const char *format, > >> va_list ap ) > >> { > >> return _vfiprintf_r( r, stream, format, ap ); > >> } > >> > >> extern int __svfiscanf_r(struct _reent *,FILE *, _CONST char *,va_list); > >> int __svfscanf_r( struct _reent *r, FILE *stream, const char *format, > >> va_list ap ) > >> { > >> return __svfiscanf_r( r, stream, format, ap ); > >> } > >> #endif // #ifdef LUA_NUMBER_INTEGRAL > >> > >> What it does is link against special versions of the printf/scanf > >> functions (vfiprintf/vfiscanf) that have no floating point support > >> whatsoever. This used to work in the past and showed a clear > >> improvement in the image size. If it doesn't work anymore, a couple of > >> things come to mind: > >> > >> - a broken Newlib build that doesn't ignore floating point operations > >> for vfiprintf/vfiscanf as it should > >> - FP functions are pulled in by other part(s) of the code > >> > >> However, this seems to work on my fairly new master: > >> > >> ~/work/elua/elua [master] $ lua build_elua.lua board=et-stm32 prog > >> Generating binary image elua_lua_stm32f103re.bin... > >> text data bss dec hex filename > >> 227368 1536 1988 230892 385ec elua_lua_stm32f103re.elf > >> ~/work/elua/elua [master] $ lua build_elua.lua board=et-stm32 prog > >> target=lualong > >> [TARGET] elua_lualong_stm32f103re.bin > >> Generating binary image elua_lualong_stm32f103re.bin... > >> text data bss dec hex filename > >> 190744 1532 1988 194264 2f6d8 elua_lualong_stm32f103re.elf > >> > >> The difference most likely indicates that the FP functions are not > >> pulled in, so I'm guessing there's a problem with your particular > >> toolchain (I'm using arm-none-eabi-gcc (Sourcery G++ Lite 2011.03-42) > >> 4.5.2 in Linux). > >> One more question: how did you find out that the floating point > >> libraries are pulled in the binary? What symbol(s) gave it away? > >> > >> Thanks, > >> Bogdan > >> > >> > > >> > Thanks > >> > Karoly > >> > > >> > > >> > _______________________________________________ > >> > eLua-dev mailing list > >> > [hidden email] > >> > https://lists.berlios.de/mailman/listinfo/elua-dev > >> _______________________________________________ > >> eLua-dev mailing list > >> [hidden email] > >> https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > > eLua-dev mailing list > > [hidden email] > > https://lists.berlios.de/mailman/listinfo/elua-dev > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by james osburn
On Mon, Jul 23, 2012 at 1:15 AM, james osburn <[hidden email]> wrote:
> using code soucery lite and removing the other path elements pointing to the > 30 day install addressed the issue. That's rather interesting, thank you. I find it extremely interesting that the lite and commercial versions have different layouts. We might want to address these kind of problems in the future with our build system. Best, Bogdan > james > > > On Sun, Jul 22, 2012 at 4:26 PM, james osburn <[hidden email]> wrote: >> >> I am going to use the lite edition : >> >> Sourcery CodeBench Lite 2012.03-56 for ARM EABI >> >> and make sure its path is in the front of the path. >> actually my only reason for building elua so include scripts as part of >> the binary. >> >> James >> >> On Sun, Jul 22, 2012 at 4:22 PM, Karoly Molnar <[hidden email]> >> wrote: >>> >>> Yes, on windows. Seems it works without hacking with the Lite edition >>> only. >>> >>> Karoly >>> ________________________________ >>> Date: Sun, 22 Jul 2012 16:17:26 -0500 >>> From: [hidden email] >>> To: [hidden email] >>> Subject: Re: [eLua-dev] inc\newlib/devman.h:7:19: fatal error: reent.h: >>> No such file or directory >>> >>> >>> Are you building on windows as well? also I have the 30 day version of >>> code sourcery not the light version. >>> James >>> On Sun, Jul 22, 2012 at 4:08 PM, Karoly Molnar <[hidden email]> >>> wrote: >>> >>> I just had the same issue couple of hours ago. >>> I managed to push the compilation forward by hacking the code by >>> replacing <reent.h> to <sys/reent.h> in all relevant locations, but finally >>> ended up in other missing macros. >>> I have a full Codesourcery license, but it appears to have different >>> content than the Lite edition. I have then just installed a fresh Lite to a >>> different folder and reverted my previous hacks. I have set the Lite edition >>> ahead of the full install in my windows PATH and now it builds correctly. >>> >>> ________________________________ >>> Date: Sun, 22 Jul 2012 15:20:07 -0500 >>> From: [hidden email] >>> To: [hidden email] >>> Subject: [eLua-dev] inc\newlib/devman.h:7:19: fatal error: reent.h: No >>> such file or directory >>> >>> >>> I am getting the following error listed in the subject line and I looked >>> up the error in the mail list archive and did find it mentioned in a >>> previous post. I then followed the fix, which was to make sure that the >>> paths to the compiler were set correctly. >>> I removed the code source install cleaned up the path and used an >>> un-installer >>> to remove any previous installs. Then ran the following but the error >>> persists. >>> >>> C:\Users\josburn\Documents\programming\elua>scons target=lua >>> board=ek-lm3s9b92 c >>> pumode=thumb toolchain=codesourcery >>> scons: Reading SConscript files ... >>> WARNING: unable to determine version from repository >>> >>> ********************************* >>> Compiling eLua ... >>> CPU: LM3S9B92 >>> Board: EK-LM3S9B92 >>> Platform: lm3s >>> Allocator: newlib >>> Boot Mode: standard >>> Target: lua >>> Toolchain: codesourcery >>> ROMFS mode: verbatim >>> Version: unknown >>> ********************************* >>> >>> Building ROM File System... >>> Done, total size is 1 bytes >>> >>> scons: done reading SConscript files. >>> scons: Building targets ... >>> arm-none-eabi-gcc -o src\main.o -c -mcpu=cortex-m3 -mthumb >>> -mlittle-endian -Os - >>> fomit-frame-pointer -ffunction-sections -fdata-sections >>> -fno-strict-aliasing -Wa >>> ll -DELUA_BOARD=EK-LM3S9B92 -DELUA_PLATFORM=LM3S -D__BUFSIZ__=128 >>> -DELUA_CPU=LM3 >>> S9B92 -DELUA_CPU_LM3S9B92 -DELUA_BOARD_EKLM3S9B92 -DELUA_PLATFORM_LM3S >>> -DLUA_PAC >>> K_VALUE -DELUA_ENDIAN_LITTLE -DLUA_OPTIMIZE_MEMORY=2 -DFORLM3S9B92 -Dgcc >>> -DCORTE >>> X_M3 -Iinc -Iinc\newlib -Iinc\remotefs -Isrc\platform -Isrc\lua >>> -Isrc\modules -I >>> src\platform\lm3s -Isrc\uip -Isrc\fatfs -Isrc\platform\lm3s\inc >>> -Isrc\platform\l >>> m3s\driverlib -Isrc\platform\lm3s\usblib >>> -Isrc\platform\lm3s\usblib\device src\m >>> ain.c >>> In file included from src\main.c:6:0: >>> inc\newlib/devman.h:7:19: fatal error: reent.h: No such file or directory >>> compilation terminated. >>> scons: *** [src\main.o] Error 1 >>> scons: building terminated because of errors. >>> >>> Here is the system setup for my pc. >>> My path is as follows: >>> >>> C:\Users\josburn\Documents\programming\elua>echo %path% >>> >>> C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\Wind >>> owsPowerShell\v1.0\;C:\Program Files\TortoiseSVN\bin;c:\Program Files >>> (x86)\popl >>> er;C:\Program Files\IVI Foundation\VISA\Win64\Bin\;C:\Program Files >>> (x86)\IVI Fo >>> undation\VISA\WinNT\Bin\;C:\Program Files (x86)\IVI >>> Foundation\VISA\WinNT\Bin;C: >>> \Python27;C:\Python27\Scripts;c:\Program Files (x86)\Microsoft SQL >>> Server\100\To >>> ols\Binn\;c:\Program Files\Microsoft SQL >>> Server\100\Tools\Binn\;c:\Program Files >>> \Microsoft SQL Server\100\DTS\Binn\;C:\Program Files >>> (x86)\CodeSourcery\Sourcery >>> _CodeBench_for_ARM_EABI\bin;; >>> >>> The version information for the compiler is: >>> >>> C:\Users\josburn\Documents\programming\elua>arm-none-eabi-gcc --version >>> arm-none-eabi-gcc (Sourcery CodeBench 2012.03-28) 4.6.3 >>> Copyright (C) 2011 Free Software Foundation, Inc. >>> >>> james >>> >>> _______________________________________________ eLua-dev mailing list >>> [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> >>> >>> _______________________________________________ eLua-dev mailing list >>> [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev >>> >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |