Want to help D compiler development: Two possible weekend projects
David Nadlinger
see at klickverbot.at
Sat Feb 2 16:37:54 PST 2013
Hi all,
in case you have an afternoon or two to spare, here are two ideas
how you could help with D compiler development (DMD/GDC/LDC):
1) Provide an Open Source clean-room implementation of
response_expand, the function the DMD frontend uses to parse
response files. Unfortunately, it is under the copyright belongs
(partly?) to Symantec, so Walter can't simply re-license it for
use in GDC/LDC, where it is needed to provide DMD compatibility
(gdmd/ldmd). For the full discussion, see:
http://forum.dlang.org/thread/kdce69%24303k%241@digitalmars.com
2) Write an ABI fuzzer: The C ABI can be quite complex to
implement on some systems, notably x86_64 Posixen (i.e. the AMD64
System V ABI). There has been a number of issues in the past (see
e.g. the infamous
http://d.puremagic.com/issues/show_bug.cgi?id=5570), but while
most of the cases frequently occurring in common C APIs are
handled correctly now, there are still a number of issues
remaining.
What makes working on the related compiler code annoying, at
least for me, is that test cases are few - bugs comings from ABI
issues are hard to track down for most non-compiler people - and
cumbersome to write/build manually, as you need to integrate the
D part with another one compiler by the host C compiler.
Thus, the idea is to write a tool which randomly generates
function prototypes and creates both C and D 'caller' and
'callee' functions with that signature. The caller supplies a
defined value for each parameter, and the callee in the
respective other language checks if it was passed correctly. Same
in the other direction for the return value.
The tool then compiles the files, links them together, and
executes the test case. It will be beneficial for throughput to
batch multiple function pairs together into one pair of source
files. If any check fails, the test executable returns with an
error code (or a segfault, ...), causing the fuzzer to save away
the offending test case. If not, the next set of tests will be
generated, and so on.
It might make sense to bias the parameter type generator towards
"complex" types containing unions, packed structs, varargs, etc.
In any case, it should be able to find issues on x86_64 in the
latest released versions of both DMD (3-byte structs) and LDC
(small structs passed as varargs when there are still registers
available).
David
More information about the Digitalmars-d
mailing list