[openbeos] Re: a new release of gcc-2.95.3 is available

On 2004-10-25 at 20:38:13 [+0200], François Revol wrote:
> > These are the main changes as compared to the last release:
> > 
> > - the resulting executables no longer crash the *broken* dynamic
> > loader on
> >   BONE/Dano/Zeta.
> Well, the elf loader in BeOs is quite weak anyway...
> What exactly is broken in there ?

Short answer: the loader doesn't like R_386_NONE relocation entries with an 
offset of zero.

Full story (dig this): Part of the dynamic loading process is the 
relocation of several entries inside the binary to its real position in 
memory. The linker generates the neccessary relocation entries, telling the 
loader for each relocation, what kind of relocation is to be done (type) 
and where the relocation takes place (offset into the binary-section). 
These relocation entries live in several sections named ".rel."...
The linker from binutils-2.15 seems to do some more optimization than older 
linkers, converting unneeded relocation-entries (pointing to sections that 
were discarded during the link) to the R_386_NONE type, which in fact 
means: "do nothing". The offset of these relocation entries is set to 0.
        [Sidenote: it would be better to remove this entries altogether, but 
        that could change the size of an already layed-out section, which - 
        according to the binutils maintainers - is difficult, so the free space 
        is not yet reclaimed by ld].
Now it seems that the newer dynamic loader is a bit peculiar about how to 
handle these "do nothing" requests: it is perfectly happy to nothing at 
most offsets, only offset 0 it doesn't like at all, as it then tries to 
execute code like the following:
        xor eax, eax
        movl (eax), eax
which, naturally, crashes the machine.

As patching the kernel provided no solution (it rendered the system 
unbootable), the solution to this was to leave the original offset of these 
relocation entries in place, just change the type to R_386_NONE. This hack 
seems to work for all BeOS dynamic loaders.

> > 
> > - GLTeapot (and other software using BDirectWindow) is now working
> > properly.
> I'm not sure I see in what way that's related to gcc...

Isn't it obvious? >;oP 
It took me some time to grasp this one, too:
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.
The news 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 the crash.
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 
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...

> > 
> > - readline is now part of the distribution, since Be distributed it
> > as
> >   part of their gcc-releases, too (the bundled version is readline-
> > 5.0).
> Btw, I noted with bash that readline has some issues when it comes
> to multibyte char handling (UTF8).
> Say you type:
> ls Préfé
> and hit backspace, of course it only deletes the last byte of
> the last char which is a 2-bytes one. Also, the display is
> shifted by one char each time.
> Do you know if there is a fix for that in recent readline ?
> It's not really a bug but it's annoying.

Let's call it an annoying bug then >:o)

I don't know for sure if the problem is really part of readline, but I 
think if it was, it should be fixed by now, since readline-5.0 mentions 
lots of multibyte-related fixes in its changelog.

cheers,
        Oliver

Other related posts: