Hello again!
In the freetype-devel list, I got some suggestions: This bug/problem seems to concentrate on ppc32/64 and s390 architectures. Basically all Type1 fonts shipped with X11 are suspect to this problem. I made tests agains UTBI____.pfa
The possible (temporary)fix: If I re-compile freetype with -fno-strict-aliasing I can get mkfontscale to work! It's still not clear whether this is a problem in freetype (2.1.7 to 2.1.9 at least), the macros there, or in gcc.
Please see the following links for more information on this problem (also referred as 'aliasing issues in freetype macros'):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=118021 http://rpm.sh-linux.org/rpm-index-2004/sh4/freetype-utils-2.1.7-4.sh4.html http://lists.freedesktop.org/pipermail/x-packagers/2004-March/000010.html https://svn.uludag.org.tr/paketler/trunk/media-libs/freetype/freetype-2.1.9-r1.ebuild http://archives.devshed.com/a/ml/200408-12273/strange-compilation-on-PowerPC
And my thread in freetype-devel: [ft-devel] Bug on PowerPC: Illegal Intruction in FT_Get_Name_Index
Currently don't feel confortable to deal with the freetype-type1-driver code which seems pretty nasty. (I am not into font-writing at all). Possible fixes might get discussed at the freetype-devel list. Suggestions are welcome to further track down the problem. But I first need to get X working on my platform...
Best greets,
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
Clemens Koller wrote:
Hello, Dan!
I did some more debugging on that problem. This bug was also reported on this list: http://gcc.gnu.org/ml/gcc/2004-07/msg00861.html
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 mentioned below)
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).
(ppc, mpc8540, gcc-3.4-20040401 or gcc-3.4.3, binutils-2.15.96)
So, the first basic question: Is the above code okay? Is the stack just trashes? I am not much into ppc assembly code. Maybe I need a helping hand. I can also let you ssh onto that machine if it's of any use.
For me, I try to get what you said... <learning...>
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.
Daniel Kegel wrote:
Clemens Koller wrote:
+ ../../../exports/bin/mkfontscale /usr/X11R6/lib/X11/fonts/Type1 make[4]: *** [install] Error 132
Can you try to produce a standalone test case that doesn't require building all of X? e.g. can you save the preprocessor output from the mkfontscale compiler run, compile that on a different system, and reproduce the problem, preferably with a single known font file? - Dan
