[Fribidi-discuss] Relocations

[Behdad Esfahbod]

Hi Owen,

Thanks for your mail, nice technical problems.

I fixed the first one (added "static const" to them).
Let me know if there is any extra symbol exported somewhere.

And about the second idea, I will work more tomorrow, better to study 
for two final exams I have tomorrow.

behdad


On 10 Jan 2002, Owen Taylor wrote:
> I was looking at updating the copy of fribidi in Pango to something
> more recent (what's in there currently is from April of last year).
> 
> Doing this, I discovered two problems with the data structures:
> 
>  - static is missing on the arrays, so a lot of symbols are exported
>    publically that don't need to be.
> 
> ===
> diff -u -p -r1.3 fribidi_create_char_types.c
> --- fribidi_create_char_types.c	2002/01/03 15:31:24	1.3
> +++ fribidi_create_char_types.c	2002/01/10 21:12:34
> @@ -101,7 +101,7 @@ get_type (char *s)
>  }
>  
>  #define table_name "FriBidiPropertyBlock"
> -#define key_type_name "FriBidiPropCharType"
> +#define key_type_name "static FriBidiPropCharType"
>  #define macro_name "FRIBIDI_GET_TYPE"
>  #define function_name "fribidi_get_type"
>  #define char_type_name "FriBidiCharType"
> ===
> 
>    Fixes most of the problem.
> 
>  - There are a _lot_ of arrays pointing at each other. Each
>    pointer to a separate symbol is a separate relocation that
>    needs to be done when the library is loaded, slowing down
>    loading. What's more since relocations require writing
>    to the library, the data won't be shared between different
>    applications using the library.
> 
>    What should be done here is to use a single array per level
>    and store offsets into that. (Probably will save some memory
>    as well.)
> 
>    The Unicode tables in glib were recently fixed up to work
>    like this, so the files in glib-1.3.12 (say gunichartables.h)
>    should provide an example of how this is done.
> 
> Regards,
>                                         Owen

-- 
Behdad
22 Dey 1380, 2002 Jan 12

[Finger for Geek Code]