[ft-devel] Bug on PowerPC: Illegal Intruction in FT_Get_Name_Index

[Clemens Koller]

Hello!

Well, about a year ago, we/you have had problems when building X11
that mkfontscale crashes while processing Type1 fonts with an illegal 
instruction
on powerpc. This was described several times in the archives, but I cannot
find a bugfix for that problem.

Here is the old mail:
[Devel] [BUG] freetype2 CVS/HEAD: crash in FT_Get_Name_Index (ftobjs.c:2407)
http://lists.gnu.org/archive/html/freetype-devel/2004-04/msg00051.html
This bug was also reported on the gcc mailing-list:
http://gcc.gnu.org/ml/gcc/2004-07/msg00861.html

I am running into the same problems again (and several others did).
Even with a pretty new toolchain:
gcc-3.4-20050401 (3.4.4)
X11R6.4.2
glibc-2.3.4
binutils-2.15.96
freetype-2.1.9
I am pretty convinced that this is not a compiler bug as I've
tried it with gcc-3.3.3 also and the guys at gcc-devel don't
have an idea also, as they cannot spend the time to check
all the freetype code!

To reproduce the problem:
install freetype-2.1.9
    ./configure
    make
    make install
compile X
    make World
everything fine
    make install

when mkfontscale tries to
+ ../../../exports/bin/mkfontscale /usr/X11R6/lib/X11/fonts/Type1
make[4]: *** [install] Error 132
(Illegal instruction)

It doesn't matter, which Font it processes - UTBI____.pfa is
i.e. sufficient to reproduce the error.

I ran into the same problem again and again. This only happens
with the Type1 fonts (the others build fine!)
My host is a embedded PowerPC from Freescale (MPC8540, e500 core, no fpu)

I've applied also this 'fake-patch' for the macro as mentioned
in the above mail msg00861.html. (inserting a dummy printf("");)
But this doesn't fix the problem on my platform.

I did some more debugging on that problem.
To isolate it for the first step it's sufficient to only build
mkfontscale within <...>/xc/programs/mkfontscale
and then call it with mkfontscale Type1 (as already mentioned)

And then, the fun starts: (let me just recite the old mail)

Compilation of mkfontscale is ok, but its execution is quite strange.
In the source code of mkfontscale, a call to a function of freetype-2.1.9
is made : FT_Get_Name_Index() in freetype-2.1.9/src/base/ftobjs.c:3279

In the source code of this freetype function, a call to another function
of freetype is made : FT_FACE_LOOKUP_SERVICE()

The full code of the function FT_Get_Name_Index() is :

FT_EXPORT_DEF( FT_UInt )
 FT_Get_Name_Index( FT_Face     face,
                    FT_String*  glyph_name )
 {
   FT_UInt  result = 0;
   if ( face && FT_HAS_GLYPH_NAMES( face ) )
   {
     FT_Service_GlyphDict  service;
     FT_FACE_LOOKUP_SERVICE( face,
                             service,
                             GLYPH_DICT );
     if ( service && service->name_index )
       result = service->name_index( face, glyph_name ); /*CRASHES HERE*/
   }
   return result;
 }


I am not finished with anlysing the code...
but on my target it crashes on the same place after the
0xff4a988 <FT_Get_Name_Index+176>:      blrl
instruction. So, it jumps out of executable code
to some 0x10034cxxsomething until it hits an illegal
instruction (after about 4 steps).

So, the first basic question: Is the above code okay?
Is the stack just trashed?

If I check the freetype-2.1.9/include/freetype/internal/services/svgldict.h:

  typedef FT_UInt
  (*FT_GlyphDict_NameIndexFunc)( FT_Face     face,
                                 FT_String*  glyph_name );

  FT_DEFINE_SERVICE( GlyphDict )
  {
    FT_GlyphDict_GetNameFunc    get_name;
    FT_GlyphDict_NameIndexFunc  name_index;  /* optional */
  };


I am really worried that the code deliveres some
bad pointers which crashes at least ppc machines more
often as the stack gets corrupt?!

I spent already several days to track down that problem,
so hopefully I'll find help on this list!!
I can also let you ssh onto my machine if it's of
any use. I really need to get this fixed!

Thank you, so far!

Clemens

Dump of assembler code for function FT_Get_Name_Index:
0xff4a8d8 <FT_Get_Name_Index>:  stwu    r1,-32(r1)
0xff4a8dc <FT_Get_Name_Index+4>:        mflr    r0
0xff4a8e0 <FT_Get_Name_Index+8>:        bcl-    20,4*cr7+so,0xff4a8e4 
<FT_Get_Name_Index+12>
0xff4a8e4 <FT_Get_Name_Index+12>:       stw     r30,24(r1)
0xff4a8e8 <FT_Get_Name_Index+16>:       mflr    r30
0xff4a8ec <FT_Get_Name_Index+20>:       stw     r31,28(r1)
0xff4a8f0 <FT_Get_Name_Index+24>:       mr.     r31,r3
0xff4a8f4 <FT_Get_Name_Index+28>:       stw     r0,36(r1)
0xff4a8f8 <FT_Get_Name_Index+32>:       stw     r28,16(r1)
0xff4a8fc <FT_Get_Name_Index+36>:       li      r28,0
0xff4a900 <FT_Get_Name_Index+40>:       lwz     r0,-16(r30)
0xff4a904 <FT_Get_Name_Index+44>:       stw     r29,20(r1)
0xff4a908 <FT_Get_Name_Index+48>:       mr      r29,r4
0xff4a90c <FT_Get_Name_Index+52>:       add     r30,r0,r30
0xff4a910 <FT_Get_Name_Index+56>:       beq-    0xff4a990 
<FT_Get_Name_Index+184>
0xff4a914 <FT_Get_Name_Index+60>:       lwz     r0,8(r31)
0xff4a918 <FT_Get_Name_Index+64>:       andi.   r9,r0,512
0xff4a91c <FT_Get_Name_Index+68>:       beq-    0xff4a990 
<FT_Get_Name_Index+184>
0xff4a920 <FT_Get_Name_Index+72>:       lwz     r11,128(r31)
0xff4a924 <FT_Get_Name_Index+76>:       lwz     r3,40(r11)
0xff4a928 <FT_Get_Name_Index+80>:       cmpwi   cr7,r3,-2
0xff4a92c <FT_Get_Name_Index+84>:       beq-    cr7,0xff4a9b4 
<FT_Get_Name_Index+220>
0xff4a930 <FT_Get_Name_Index+88>:       cmpwi   cr7,r3,0
0xff4a934 <FT_Get_Name_Index+92>:       bne-    cr7,0xff4a960 
<FT_Get_Name_Index+136>
0xff4a938 <FT_Get_Name_Index+96>:       lwz     r10,96(r31)
0xff4a93c <FT_Get_Name_Index+100>:      lwz     r9,0(r10)
0xff4a940 <FT_Get_Name_Index+104>:      lwz     r0,32(r9)
0xff4a944 <FT_Get_Name_Index+108>:      cmpwi   cr7,r0,0
0xff4a948 <FT_Get_Name_Index+112>:      bne-    cr7,0xff4a9bc 
<FT_Get_Name_Index+228>
0xff4a94c <FT_Get_Name_Index+116>:      cmpwi   cr7,r3,0
0xff4a950 <FT_Get_Name_Index+120>:      mr      r0,r3
0xff4a954 <FT_Get_Name_Index+124>:      bne-    cr7,0xff4a95c 
<FT_Get_Name_Index+132>
0xff4a958 <FT_Get_Name_Index+128>:      li      r0,-2
0xff4a95c <FT_Get_Name_Index+132>:      stw     r0,40(r11)
0xff4a960 <FT_Get_Name_Index+136>:      lwz     r9,8(r1)
0xff4a964 <FT_Get_Name_Index+140>:      stw     r3,8(r1)
0xff4a968 <FT_Get_Name_Index+144>:      cmpwi   cr7,r9,0
0xff4a96c <FT_Get_Name_Index+148>:      beq-    cr7,0xff4a990 
<FT_Get_Name_Index+184>
0xff4a970 <FT_Get_Name_Index+152>:      lwz     r0,4(r9)
0xff4a974 <FT_Get_Name_Index+156>:      cmpwi   cr7,r0,0
0xff4a978 <FT_Get_Name_Index+160>:      beq+    cr7,0xff4a990 
<FT_Get_Name_Index+184>
0xff4a97c <FT_Get_Name_Index+164>:      mr      r3,r31
0xff4a980 <FT_Get_Name_Index+168>:      mr      r4,r29
0xff4a984 <FT_Get_Name_Index+172>:      mtlr    r0
0xff4a988 <FT_Get_Name_Index+176>:      blrl
0xff4a98c <FT_Get_Name_Index+180>:      mr      r28,r3
0xff4a990 <FT_Get_Name_Index+184>:      lwz     r0,36(r1)
0xff4a994 <FT_Get_Name_Index+188>:      mr      r3,r28
0xff4a998 <FT_Get_Name_Index+192>:      lwz     r29,20(r1)
0xff4a99c <FT_Get_Name_Index+196>:      lwz     r28,16(r1)
0xff4a9a0 <FT_Get_Name_Index+200>:      mtlr    r0
0xff4a9a4 <FT_Get_Name_Index+204>:      lwz     r30,24(r1)
0xff4a9a8 <FT_Get_Name_Index+208>:      lwz     r31,28(r1)
0xff4a9ac <FT_Get_Name_Index+212>:      addi    r1,r1,32
0xff4a9b0 <FT_Get_Name_Index+216>:      blr
0xff4a9b4 <FT_Get_Name_Index+220>:      li      r3,0
0xff4a9b8 <FT_Get_Name_Index+224>:      b       0xff4a960 
<FT_Get_Name_Index+136>
0xff4a9bc <FT_Get_Name_Index+228>:      mr      r3,r10
0xff4a9c0 <FT_Get_Name_Index+232>:      lwz     r4,-32732(r30)
0xff4a9c4 <FT_Get_Name_Index+236>:      mtlr    r0
0xff4a9c8 <FT_Get_Name_Index+240>:      blrl
0xff4a9cc <FT_Get_Name_Index+244>:      lwz     r11,128(r31)
0xff4a9d0 <FT_Get_Name_Index+248>:      b       0xff4a94c 
<FT_Get_Name_Index+116>
End of assembler dump.

--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19