From 2ec313f7c35a4c8240a6b50d289856496944007c Mon Sep 17 00:00:00 2001 From: Oliver Tappe Date: Fri, 4 Feb 2005 21:23:26 +0000 Subject: [PATCH] - forgot about committing this, contains updated changes (from last release). git-svn-id: file:///srv/svn/repos/haiku/trunk/buildtools@11252 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- gcc_distribution/README | 61 ++++++++++++++++++++++++++++++++--------- 1 file changed, 48 insertions(+), 13 deletions(-) diff --git a/gcc_distribution/README b/gcc_distribution/README index b8e5700c65..0f073ff415 100644 --- a/gcc_distribution/README +++ b/gcc_distribution/README @@ -91,27 +91,62 @@ Bugs/Peculiarities: entries in place, just change the type to R_386_NONE. This hack seems to work for all BeOS dynamic loaders. + - The Be-compilers had the habit of putting automatically generated functions + into each object file that uses them. This behaviour corresponds to what gcc + calls multiple symbol spaces. For ELF, however, multiple symbol spaces do + not make much sense, as all global symbols are automatically being exported + (i.e. there is only a single symbol space). + This version of gcc activates multiple symbol spaces only when optimization + is switched off. In optimizing mode, a single symbol space is used, in order + to yield smaller object files, libraries and apps. + You can use the new switch -f(no-)multiple-symbol-spaces to force gcc to + use (or not use) multiple symbol spaces. + - Every app is now automatically linked against a (new) object file named fix_bdirectwin_typeinfo.o - Older compilers had the habit of generating typeinfo-functions in each - object file that uses them (dynamic_cast). My version of gcc only does that - if optimization is switched off. In optimizing mode, these functions are not - kept in each object file, but they are taken from the library which "defines" - the class that is the target of the dynamic_cast. This works fine for most - cases, but the Be-libraries seem to contain a broken version of the - BDirectWindow-typeinfo-function. + As a result of the multiple / single symbol space issue, older compilers + generate typeinfo-functions in each object file that uses them (via + dynamic_cast). + As this compiler uses a single symbol space when optimizing, type-info + functions are not kept in each object file, but they are taken from the + library which "defines" the class that is the target of the dynamic_cast. + This works fine for most cases, but the Be-libraries seem to contain a + broken version of the BDirectWindow-typeinfo-function. The difference here is that older compilers never used this function, as the linker always linked to the (object-file-)internal version of this funtion. Gcc-2.95.3 doesn't always generate these, so that the one living inside the - Be-libraries is being used, which in turn leads to a crash (an example is - GLTeapot). + Be-libraries is being used, which in turn leads to a crash (examples are + GLTeapot or libSDL.so). As a solution to this problem, I have created a new object file, named fix_bdirectwin_typeinfo.o, that contains an implementation of the - BDirectWindow-typeinfo-funtion. Every app is now linked against this file - automatically (by means of the specs-file), such that the broken + BDirectWindow-typeinfo-funtion. Every app and library is now linked against + this file automatically (by means of the specs-file), such that the broken implementation from the libs isn't used. - What remains a mystery to me is how that broken function found its way into - the libs in the first place... + You can use the new switch -no-beos-fixes to switch off this fix. This is + especially useful if you are debugging small test applications and you do + not want/need the symbols from fix_bdirectwin_typeinfo.o. + What remains a mystery to me is to what respect this function is broken + and how it found its way into the libs in the first place... + + - gcc-2.95.3 is a bit more decisive when it comes to the handling of inline + assembly operand constraints. The original gcc-2.95.3 contained a bug + (or two rather) that resulted in a complaint about a "fixed or forbidden + register" bx or bp being spilled for an inline asm-clause that requires + rather a lot of register operands. This bug has been fixed (i.e. bx and + bp are now only spilled if it is safe to do so), but it's still quite + probable that inline assembly that compiled and worked for gnupro-000224 + may not compile instantly with gcc-2.95.3. + So far I have been able to fix all the inline assembly related problems by + specifying other operand constraints, but I wouldn't be surprised if there + are projects out there for which this won't work. + + - the generation of debugging info has been, and still is, problematic. So + whenever you encounter weird error messages or other strange behaviour, + please try to deactivate debug-info (remove -g from the build). + I think it is especially unwise to combine optimization with debug-info + (which a lot of opensource projects seem to do by default), as this + combination seems to be the least reliable during compilation and the + resulting apps aren't useful in the debugger either. - I believe 2.95.3 improves upon the other available compilers for BeOS, but this does not mean that it is better for all purposes, it is just different!