[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] C++ Stuff

Miro Kropacek wrote:


    One of the most annoying thing on the MiNT host it that currently,
    code has to be be compiled with GCC 2.95.3, it has a bug in the
    preprocessor so things like #if value != negative_constant returns
    the wrong result, it has to be rewritten like #if !(value ==
    negative_constant)
I think no need to panic, it isn't that bad. After some sed'ing and grep'ing, I found only one possible suspicious place -- file ./gcc/emit-rtl.c, line 439 -- here's variable STORE_FLAG_VALUE compared to both 1 and -1 (using !=) and in file ./gcc/config/m68k/m68k.h, line 827 we see it's set on -1. Assuming mint target uses this header file, it could lead to some problems. Except this I didn't find anything else. 

Good news.


    - use the ELF file format for intermediate object files. It will
unlock some GCC features 
Just to be sure -- a.out as output format will stay?

Yes.
Binutils can mix a.out and ELF object files as input, and produce the usual MiNT/a.out executable. 

> I.e. no

compatibility will be broken regarding running in TOS?
No compatibility will be broken, because the format of the output executable will remain exactly the same. 

There are several good facts :
- GCC really prefers ELF object files (soon on MiNT), but it doesn't care about the format of the final executable (as it will never use it as input). For example, most embedded targets use ELF as object file format, and produce raw ROM images, totally unusable by other tools, but perfect for the target hardware.
- Keeping the "magical" hybrid MiNT/a.out file format as output is the best thing to do, because a.out is very similar to TOS executables, and well supported in the binutils. So that format is very well supported by the linker (as output), by the other binutils tools as input (objdump, etc.), by gdb (it shares the bfd libary with the binutils), and even with the plain old TOS ! Of course, FreeMiNT could introduce another executable format (for example, to enable shared libraries support), but it is absolutely not necessary now.
- With my current incomplete ELF patch, I have been able to compile some simple C sources to ELF object files (using current GCC and the ELF-as). Then ELF-ld has merged the ELF objects of my program with the a.out objects found inside the MiNTLib installed on my system. And it produced a standard MiNT/a.out executable, working perfectly ! 
However some thing does not work yet :
* GNU debug information. I don't know how it will be usable by the binutils tools and gdb. ELF use DWARF, a.out use STABS... A lot of work to do here. * DRI symbols (for --traditional-format). Currently, the binutils patch needs a.out object files as input for generating DRI symbols (the current implementation is totally incompatible with ELF). Ok, it is not an absolute necessity, but personally I love to examine the GCC output with MonST. * GCC support for ELF features. Everything is present in the standard GCC, it has just to be enabled for the MiNT target (not as simple as that). And thinking to dive again to GCC sources with hours of compilation and debugging gives me a headache... 


Finally, some immediate benefits of using the ELF object format :
- Bugs related to a.out get away. So if we find bugs even with ELF, the gcc team will help us.
- The -ffunction-sections GCC option. With that, the linker is able to get rid of unused functions found in .o files. Currently, if a .o contains 10 functions, but only one is used by the program, all the useless functions (and their dependencies !) are linked into the final executable. I expect the executables will be much smaller with that (especially C++ ones).
- The -fPIC GCC option (about Position Independent Code). It is currently useless for us, but it is the first prerequisite for shared libraries in the GNU way. It may be useful one day...
Btw, if you need some assistance with this -- during my cooperation with Frank Wille (vasm/vlink/vbcc author/maintainer), he was just in phase he was adding ELF support into his linker (which is able to do the same you want to do -- i.e. mixing ELF obj files into a.out executable). He could provide you with some hints when you'll be feeling desperate :) 

Yes, he could give us some valuable help !
However he is working on its own linker, and I want to patch the standard GNU ld. The code is different, but the main principles are the same (debug info issues, etc...). So I will definitely ask him for help about these questions when it will be the moment. 

Hmmm... Thinking to all that stuff, I'm already tired ;-)

--
Vincent Rivière