Re: Faster UTF-8 decoding in GLib

[Mikhail Zabaluev <mikhail zabaluev gmail com>]

Hi,

2010/3/16 Daniel Elstner <daniel kitta googlemail com>:
>> I've just verified your theory with objdump -r, and it shows the
>> references as R_386_32. Do you insist that they are dynamic?
>
> Sorry for the slightly incorrect terminology.  Of course, they are not
> dynamic in the sense that they can be loaded from the outside.  But the
> table still has to be filled in by the dynamic loader at library load
> time as far as I know, because the function pointers are absolute, not
> relative addresses.
>
>> The only new dynamic symbol exposed is g_utf8_getter_table, and it's a
>> pointer const variable.
>
> Yes, I wasn't talking about 256 exported symbols, but about 256 symbol
> references that need to be resolved.  Years ago, Ulrich Drepper wrote a
> paper about optimizing shared libraries, which I highly recommend.

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. 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.

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

-- 
  Mikhail