Re: Faster UTF-8 decoding in GLib

[Daniel Elstner <daniel kitta googlemail com>]

Hi,

Am Dienstag, den 16.03.2010, 23:18 +0200 schrieb Mikhail Zabaluev:

> Umm. I had the conception of a DSO being one position-independent blob
> with all references made relative, even if basic ELF allows different
> segments loaded independently.

Impossible.  There are no relative function pointers.  Well, I suppose
you could construct such a beast at the assembler level, but plain old C
function pointers are definitely absolute within their code segment.

> I don't assume the dynamic loader
> should relocate internal function pointers, which are quite commonly
> used. A brief readup on venerable Drepper does not contradict that.
> But even if you are right, any GObject class writes function pointers
> at initialization, and glib proper uses function table stuff quite a
> lot too, so 256 more should not make extraordinary impact.

I remember this to have been a point of concern for the GRegex
implementation.

https://bugzilla.gnome.org/show_bug.cgi?id=50075#c67

The problem should be the same as with the original _pcre_utt table.

> And oddly enough, the ARM compiler does away even with the object file
> relocation entries for the table.

At some point, it needs to fill the table.  And if loading offsets are
randomized for security, there is hardly any room for optimization left.

--Daniel