/
TODO
173 lines (120 loc) · 5.96 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
## -*- mode: Text -*-
This file is not expected to be interseting/useful for people other
than Csmith's developers. It's not particularly up to date either.
-------------------------------------------------------------------------------
- optionally (turned on by default) fail to take the address of union
fields
- optionally generate GCC attributes: stdcall, may_alias, ...
- generate openmp pragmas
- optionally put all globals into a (packed) struct
- optionally put all globals into a char array
- generate code that manipulates strings
- concatenate, copy, take length, compare
- incrementally add C++ features; which ones have high value but are
easy to generate?
- exceptions
- limited use of objects
- atomics
- support "swarm testing" (see our ICSE submission on my papers
page). This is already done in my (old) drivers, but a few things
need to be redone. If someone wants to do this for the new Csmith
drivers, that would be good.
- make swarm use all options that make sense
- print platform information at the top of each generated random test
- add command line flags to disable generation of: loops,
conditionals, shifts, arithmetic (outside of loops and checksum)
- add a flag that switches between initializing all / none / random
global variables
- generate (limited) type casts
- generate ternary conditional operator
- add a flag to avoid copy-by-value of structs
- generate floating point math
- generate switch statments with random fallthroughs
- generate "register" and "inline" -- trivial!
- generate memset, memcpy, bzero, sizeof, etc.
- generate simple uses of malloc/free
- should span parts of structs, arrays, scalars, etc.
- generate C++11 memory model operations
- first, just atomics
- make output compile as C++
- Carlos Scheiddeger says:
"Most graphics cards support some form of OpenGL acceleration, and
these days this means supporting GLSL, which is a simple C
derivative. The reason this is at all interesting is that with WebGL,
(a subset of) GLSL is part of the attack surface for web
browsers. Break graphics drivers sufficiently bad and you can kernel
panic a computer from an HTML page."
- also, we should generate OpenCL / CUDA code
-------------------------------------------------------------------------------
+ Come up with a better naming convention for "platform" files for csmith
itself, versus "platform" files that make up the runtime of generated
programs. It is confusing to have both named "platform*'.
+ Fix the conditional CPU macros in "src/platform.{cpp,h}". These should
apparently refer to the *host* CPU type, not the *target* CPU type, because
the conditionally compiled functions are invoked by csmith itself, not by
the generated programs. (See how confusing it is to call everything
"platform*"?)
-------------------------------------------------------------------------------
add a command line option where random programs report on their branch
coverage. this amounts to:
- numbering the branches in the random program
- creating a global array of bools, with two bools for each branch (taken
and not taken) initialized to false
- add code following each branch that sets the appropriat flag to true
- print coverage information at the end
- for each branch: was it taken? not-taken?
- overall amount of branch coverage
-------------------------------------------------------------------------------
GENERATING TYPE CASTS
Main reference is the C standard, in particular the C99 aliasing
rules, explained intuitively here:
http://codingrelic.geekhold.com/2008/10/aliasing-by-any-other-name.html
http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html
Very useful paper:
http://www.cs.wisc.edu/wpis/papers/fse99.pdf
Probably also useful:
http://www.cs.ru.nl/~tews/cv07-slides/union_and_cast.pdf
http://www.cs.washington.edu/homes/marius/papers/tpd/tpd-popl08.pdf
http://users.encs.concordia.ca/~debbabi/pdf/Interprocedural%20and%20flow-sensitive%20type%20analysis%20for%20memory%20and%20type%20safety%20of%20C%20code.pdf
http://portal2.acm.org/citation.cfm?id=316183&dl=guide&coll=GUIDE
Can generate "restrict" qualifiers
http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-restrict-keyword.html
http://www.cs.pitt.edu/~mock/papers/clei2004.pdf
-------------------------------------------------------------------------------
Repair the effect sanity-checking in CGContext. Basically, check that
the thing you are doing doesn't interfere with the context. Note that
this is too broad:
void
CGContext::sanity_check(void)
{
if (effect_accum && !effect_context.is_side_effect_free()) {
assert(effect_accum->is_side_effect_free());
}
}
Checking for side-effects only is no good in general. We can usually
have side-effects in both the context and accum, as long as they do
not overlap.
-------------------------------------------------------------------------------
Fix what "side_effect_free" means. It should either mean side-effect
free, or it should be renamed to "volatile-free" or similar. See:
void
Effect::write_var(const Variable *v)
{
write_vars.push_back(v);
// pure = pure;
// TODO: not quite correct below ---
// --- but I think we want "side_effect_free" to mean "volatile_free".
side_effect_free &= !v->isVolatile;
// side_effect_free = false;
}
-------------------------------------------------------------------------------
ENE, Sun Jul 7 2009: Fix the handling of the generated `.h' files in `src'.
In distributions, we include both the `.m4' files and the generated `.h' files.
But we require (?) users to have `m4' at distribution build-time. Also,
running `make clean' in an unpacked distribution will remove the generated `.h'
files --- which came with the distribution.
We should either:
+ Treat the generated files more like "regular" source files in dists.
+ Just distribute the `.m4' files, and not the generated `.h' files.
-------------------------------------------------------------------------------
## End of file.