This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Big-endian in combined one-pass build
On 01/24/2011 06:55 PM, Drasko DRASKOVIC wrote:
Hi Jeff,
Thank you very much for this clarification.
I have some additional question at this point :
On Mon, Jan 24, 2011 at 11:10 PM, Jeff Johnston<jjohnstn@redhat.com> wrote:
On 01/24/2011 09:52 AM, Drasko DRASKOVIC wrote:
Questions are :
1) Why is this happening and how to force newlib to compile in BE mode ?
Normally, newlib is built with a target and using multilib. Gcc then
reports the permutations to build newlib with. When you don't use multilib,
then newlib gets built with the default options and whatever options you
override. If the default for arm-elf is to be LE, then that's what you end
up with.
I have not found how to pass GCC options to be BE. So I used armeb-elf
target, which seems only way to force GCC to BE.
However, I noticed that newlib has no support for armeb-elf atrget. is
this correct ?
There is some patch I found to force armeb-elf target in newlib :
http://sourceware.org/ml/newlib/2008/msg00698.html.
However, toolchain produced in that way (multilib disabled), although
capable to link well my software, it is creating binaries that do not
function well.
Is this patch incorrect ?
I stand corrected, there was a request. I didn't comment on it so it
got missed and the sender doesn't appear to have followed up on it. It
appears to be missing some other changes in the file which look for
arm-* and won't trigger on armeb-*. You might have fixed that on your
own, but if not, be aware.
In theory, the armeb compiler should compile with BE by default. It
should set compiler flags that can be used to figure out the float
endian-ness. See libc/include/machine/ieeefp.h for arm logic. If those
flags aren't being set or the ieeefp.h isn't interpreting correctly
under such a scenario, it might get the floating-point format wrong
which may be the cause of errors you are seeing.
If the fixes are made and the armeb-elf configuration isn't creating
valid executables, you're going to have to do some debug investigation.
Do you get through crt0 ok? Can you run a simple empty program? If
not, where are you failing? If yes, try other simple programs like
HelloWorld. Check constants and make sure they are in BE format.
No one has ever requested or added armeb-elf as a newlib target.
That is strange, considering that Crosstool disables multilib and
forces armeb-elf target when BE is selected...
So, basically this target does not exist and mentioned patch is risky ?
2) Can --with-endian=big flag work even if I disabled multilib (i.e.
is multilib necessary for BE mode build ?)
By your test results, the with-endian flag is not being used to set
compilation flags passed to newlib. Newlib doesn't interpret or do anything
with the --with-endian setting.
Yes, it seems like that. With multilib enabled I forced
--enable-biendian, which produced BE libs. They compile binaries that
seems to be fine. However patched newlib with armeb-elf target
produced bad binaries.
3) Do I always have to use armeb-elf instead of arm-elf target when
multilib is disabled
If you don't override the compilation flags manually, then yes.
OK, that would mean calling "make" with TARGET_CFLAGS variable set
correctly, right ? Would that be sufficient, or something else should
be changed in the code before ?
Depends on the questions above regarding debugging.
4) Do I have to use make CFLAGS_FOR_TARGET="-mbig-endian -msoft-float"
CCASFLAGS="-mbig-endian -msoft-float" when calling GCC (with newlib
combined, one-pass) build to force Newlib to compile in big-endian
mode ?
Actually, for newlib, use TARGET_CFLAGS="-mbig-endian -msoft-float". You
might require the CFLAGS_FOR_TARGET to ensure that other target libs are
built with the same options (e.g. libgcc).
My question here is : would TARGET_CFLAGS="-mbig-endian -msoft-float"
to affect C++ part also (i.e. would this produce BE C++ libs) ?
Can you please clarify these variables in a little more detail, as it
seems to be crucial :
1) What would be difference between TARGET_CFLAGS and
CFLAGS_FOR_TARGET, and what is the role of the CCASFLAGS ?
TARGET_CFLAGS is a flag used by newlib and is used both for compiling C
files and assembly files. CCASFLAGS are flags used to compile .S files
which are assembly files with C preprocessor statements (e.g. #ifdef
HAVE_xxxx). Newlib uses .S files for stuff such as setjmp/longjmp,
crt0. This allows a platform to change any C file over to assembly if
desired and to react to various newlib_cflags used in configure.host in
a reasonable manner (e.g. HAVE_xxxx tells the code it can make a call to
xxxx).
The TARGET_CFLAGS flag is used both for compiling newlib C files and is
used to set CCASFLAGS. You don't have to set CCASFLAGS in addition.
CFLAGS_FOR_TARGET is set from the top-level and passed to components
that are for the target (e.g. target libraries). It works for newlib
since newlib is a target library and it will be the CFLAGS variable
passed to newlib at its top-level. You might want to add in the initial
default CFLAGS_FOR_TARGET settings if you override (namely "-g -O2")
because you will stomp over these.
So, if you want to pass flags just to newlib, use TARGET_CFLAGS. If you
want to pass flags to all target libraries, use CFLAGS_FOR_TARGET.
If the armeb-elf compiler should by default be setting BE and soft-float
options, then you shouldn't be passing any flags - it should just work.
You may have to do save the build log and do some assembly debugging
to figure out what is going wrong.
2) Both GCC with C++ supptor and newlib will be compiled in combined
build calling "make" one time, and re-defining these variables. So who
will use these, GCC or Newlib, or both ? I am asking thisbecause I had
compilation breaking when issuing :
make CFLAGS_FOR_TARGET="-mbig-endian -msoft-float"
CCASFLAGS="-mbig-endian -msoft-float"
See above. You don't need to set CCASFLAGS.
What would be correct "make" invocation then, having in mind that I'd
like to disable multilib and use toolchain to compile and link code
for big-endian ARM946ES ?
Thank you very much again for your time.
Kind regards,
Drasko