[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 

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


Other related posts: