Hi,
On 08/01/2015 16:22, James Cowgill wrote:
> Source: ocl-icd
> Version: 2.2.3-1
> Severity: important
>
> Hi,
>
> ocl-icd FTBFS on mips64el due to the failure of the test
> "5: Our dummy ICD through our ICD loader"
>
> The full log is here, but doesn't contain much detail:
> http://mips64el.debian.net/debian/buildlog/o/ocl-icd_2.2.3-1/ocl-icd_2.2.3-1_mips64el-20141231-1651.build
>
> The tail of testsuite.log contains:
>> 83 : clSetMemObjectDestructorCallback
>> 84 : clCreateUserEvent
>> 85 : clSetUserEventStatus
>> 86 : ./testsuite-standard.at:48: exit code was 139, expected 0
>> 5. testsuite-standard.at:45: 5. Our dummy ICD through our ICD loader
>> (testsuite-standard.at:45): FAILED (testsuite-standard.at:48)
>
> I had a look at the segfault and it appears the stack was being corrupt
> by some dodgy function calls in the test.
>
> The dummy ICD test attempts to call all the OpenCL functions using a
> dummy ICD but for simplicity calls them with only 2 arguments (see
> run_dummy_icd_gen.c + run_dummy_icd_weak_gen.c)
>
> Function 86 in the list is clEnqueueReadBufferRect (found in
> ocl_icd_loader_gen.c). The key property of this function is that it has
> a 32-bit integer parameter beyond the 8th argument. The MIPS n64 ABI
> says that this argument must be passed on the stack and sign extended to
> 64-bits. To ensure this, GCC inserts a load and store to sign extend the
> value during the call:
> RETURN(((struct _cl_command_queue
> *)command_queue)->dispatch->clEnqueueWriteBufferRect
> but because the ICD test only passes 2 arguments instead of the required
> number, the above line ends up corrupting some random part of the
> previous function's stack space.
>
> Clearly the "correct" way of fixing this is to pass the correct number
> of arguments, but if that introduces too much complexity you could just
> disable the test on mips64* due to the ABI being incompatible with it.
Thank you very much for your very detailed analysis.
For the time being, I will just, indeed, disable the test.
And Brice and I will think to a way to make it more robust
(perhaps by not using standard headers to avoid this kind
of problem, or by finding a way to autogenerate the good
API)
Regards and thanks again
Vincent
> Thanks,
> James
>
--
Vincent Danjean GPG key ID 0xD17897FA [email protected]
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
