Bug#710336: some observations
graphite2 also FTBFS on alpha and sparc64 at debian-ports. It appears
to me that the common factor between the build failures (armel,sparc,
sparc64,alpha) is that they are all RISC CPUs requiring strict alignment
on memory accesses. I would bet on a misaligned memory access somewhere
in the code, but not an actual issued misaligned access (as this will cause
kernel traps on at least alpha and that does not occur) but one where the
compiler thinks it should be aligned so issues an aligned memory access
but ends up reading/writing the wrong thing. I've seen bugs like that
before in code compiled on alpha, but it is no use reporting to the gcc
developers as they will just point to the "undefined behaviour" bit of the
standard and remind you that they are well within their rights to wipe your
hard disc drive in such circumstances and one should be glad that they
didn't.
Sparc is big-endian (IIRC) and the others little-endian so endianess is
unlikely to be the cause.
The graphite2 library code is instrumented at every step with checks on the
read font. These are tripping out and just about every test fails because
the font is failed to be read. I instrumented the code somewhat and found
on armel that the first test "padauk1" in the test suite trips at Pass.cpp
lines 200 and 201 in Pass::readRules(). In my test rc_begin had the value
0xb9740e which is greater than rc_end with the value 0xb97316. Ouch.
When run on alpha the first test "padauk1" got a little bit further before
it tripped at Code.cpp line 310 in Machine::Code::decoder::fetch_opcode()
with 4 passed as both arguments to valid_upto() and as 4 is not less than
4 valid_upto() calls failure() to flag an "out_of_range_data" error in
reading the font.
Interestingly graphite2 compiles correctly and passes the test suite if
I add the compiler flag -mcpu=ev67 to the build on alpha. In Debian we
compile for generic alpha thus all byte/word accesses to memory are
implemented as (aligned) longword (32bit)/quadword (64bit) accesses
with the byte or word extracted from the longword/quadword with CPU
register instructions. This enables Debian alpha to be run on all alphas.
Specifying -mcpu=ev67 activates the byte-word extension, thus permits the
compiler to issue actual byte or word memory accesses supported by only
the more recent alpha hardware.
A speculation: maybe some byte/word accesses are aliased and the
compiler does not realise this, so optimises code to achieve a cock up
if forced to access memory as longwords/quadwords as required on generic
alpha.
However, I am not sure if armel/sparc are so limited as alpha on byte/word
accesses...
I have not got any further than this in my investigations.
Cheers
Michael.
Reply to: