[openbeos] Re: gcc 3.x ABI
- From: "Thierry Delhaise" <delhaise.t@xxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 18 Sep 2002 14:27:47 GMT
> >I'm not sure about what you mean ? ;-) Does the ml "openbeos" is not
> >interest about the (future and specs of) tools use by the OS.BOS
> >projects ?
> >
> >;-)
>
> We are really trying to keep this list focused on today. Today's
> tools and today's issues.
For sure ! I agree with you ! On the kernel side. My question as I
explained to axel out of the list was for our guys who have made some
developments under Linux with the gcc 3.2 and tried to port those
developments under BeOS. We think ours developments can be suitable for
End Users OpenBeOS and BeOS community. ;-) I will tell you more in the
future ;-)
So they have tried to compiled with the original Be gcc and with gcc
2.95.3/binutils 2.10.1 and have a lot of compilations errors. All the
development have been made with C++ and Exceptions managements,
templates and RTTI and they rely on libstdc++-3. So, I just let you
imagine what they have to change if they don't have a gcc3 suite under
BeOS.
Because I've start to work on bootloader, PCI stuff on OBOS Kernel and
I must deal with some assembler code, I've decide to take a detail view
on how Be's compiler suite work : we all know that before binutils 2.10
we can't get ride of mixing 16 bits and 32 bits code on Intel and if
you decide to code those things, we have to know perfectly what our
compiler, assembler, linker is able to do and not !
Another thing : When I came on BeOS development world (some month ago ;
-), I've heard a lot of things about the 2.95.3/binutils 2.10.1 port of
BeBits. Anybody told me to not use it, but never say why ?. So I was a
little bit frustrated !
Now, I 've took time to analize "why" and will send to the community in
futurs days the result. I think, all of us, receive a lot of questions
(like mines some months ago ;-) about 'why we don't use it', ' when
gcc3 will be available on BeOS', what it will be able to do ?', what
works on ? and not, does the base compiler is able to work for all or
not !
Since now 3 days I'm working full time on analizing how ours compilers
suites work and I can tell you that :
- the gcc 2.95.3/binutils 2.10.1 was port only by taking care to
reimplement inside this new versions, all the ack made by Be under the
gnupro suite. None of the ports (I have found two ports of this suite
on the Net, and they are quiet different) was analize to verify if the
Be's ack under 2.9 was correct on a newer version ! None of the ack of
Be were send to binutils or gcc teams for validation (I've took contact
with both teams and sent them just the diffs file we find today in the
"patch" directory of the BeBits gcc/binutils suite and none of those
diff's are registered !!! ). So all the guys working officialy under
our tools at gcc or binutils never take care of our OS constraints, our
bugs for now). I let you imagine the work we will have to do if we
decide to work on the compiler when we will reach R1 :-(
- I've took time to download the 2.95.3/binutils 2.10.1 sources and all
the require stuff needed by the "testsuite" of gcc/ld (it required me
to port a lot of tools and check if those ports was suitable under
BeOS) : the 2.95.3/and binutils 2.10.1 for BeOS only achieves 30% of
the test with the hack of Be !!!!! : objcopy don't work, objdump too
(yes it runs, but what they display or return is wrong !!!), ld corrupt
our executables, debug symbols are sometimes invalid, gas generate
assembler code note suitable for target platform, some jump offset are
sometimes invalid etc...
- I've check the archive on 2.9 patchs (gcc and binutils) submit after
the version we are currently using and I can tell you that there is a
lot of bad things inside ! Things that generate bugs we don't allways
understand ;-)
For example, if you take a look at the source provide by Be for the
gnupro, you can see that they take care of "fseek" stuff special under
BeOS which could generate some garbage inside your object or executable
file. Near this one, some month later after 2.9, there was a patch
where the binutils team take care of a condition where themselve were
corrupting the file with some bad code ! And we don't have this patch
apply with our originals tools ! There is another big one : if inside a
function you declare a static buffer (static char zero[512]; for
example, allocate on stack so), the compiler should take care to
initialize buffer with '0'. That's a compiler issue about static
variables! If you compile your code with 2.9 from Be and you ask for
optimisation (-Ox), there is some cases where your static buffer will
never be initialize with 0 values.This is due to invalid optimization
pass on certain condition ! And if you take a look at Be's ack about
fseek in 2.9, you can see that they use this stuff to correct the bug ;
-) Interesting, isn't it ? One correction which generate another bug !
This one is correct by default on 2.95.3 ! Not inside our version ! He,
he ! So, I can just say one thing for now : use memset anyway and in
any condition if you plan to trust -Ox flags !!!! (it's a joke with
axel and marcus ;-)
So, if i've to suggest something for now, cross compil from another
platform today since those tools version could give us a better result
than under BeOS ;p ! Or definitly take decision to change the compiler
and binutils suite with a correct one ! But for BeOS, none of those
exist :-( !
In conclusion, you're right Michael ! We need to work with tools we
know, and on which we could trust ! That's what I was thinking when I
firstly post on this subject.
So, if inside this list someone start some work on one compiler (3.x or
2.9[0-6]) other than the Be's one, may be he can share here is work and
his investigations for all the community ?
> Always changing, the future is. Back a year ago, everyone thought
> that we should go to gcc3.0, for example, because it was a new ABI and
certainly it wouldn't change any time in the near future. ;-)
>
> OTOH, this topic is appropriate for the kernel mailing list, since we
> (Team Kernel) could and may well build with something newer than 2.95.
Since the Kernel Kit's API is C and not C++, we can get away with a lot
more. And the extra performance will help everyone. ;-)
>
For sure ! I will detail all my current work when I will have something
suitable for all the team : I'm currently investigating to know what's
cheaper : correct Be'one ? Jump to 2.95.3 ? or switch to 3.x ? but it
will take me certainly a long time since I'm not a compiler's guru and
I only have some basic knowledge of elf !
Best Regards
Thierry
Other related posts:
