mrs wrote: > [...] The question is, how decent are the results and can you spot > any systematic wrongs that appear and/or can you identify any > non-portableness to darwin of mudflap? I started from 89 > passes... > :-) [...]
Most of the FAILs are "output pattern test" failures, related to some mf-runtime.c problem locating "nearby" objects in mudflap error messages. Maybe this code has signedness problems on darwin. Maybe the malloc's from the test cases weren't being interposed at all. For dynamic linkage, this requires your dynamic linking system to resolve malloc-related calls to libmudflap, whence dlsym(RTLD_NEXT..) can find the system malloc. Try building one of the test cases by hand, and run it with env MUDFLAP_OPTIONS="-trace-calls". You should see the registration (corresponding to malloc), and a number of successful checks, and at an unsuccessful check. The heap-scalestress FAIL may relate to a mf-hooks* or mf-runtime.c portability problem, where an object registration is attempted that overlaps the startup-time registration of the stdin/out/err FILE objects. A trace would again help. Similar to Jim Wilson's findings, the stdio-related mf-hook* calls may need autoconf parametrization to do the right thing on your libc. This problem is triggered by a few other tests too. The hook-allocstuff FAIL may again relate to malloc/realloc interposition problems, as might pass11/12/16/... A "-trace-calls" run should again help identify the culprit. The pass-stratcliff FAIL may relate to the absence of a stpncpy/mempcpy declaration or implementation on darwin. The pass35 FAIL may be a darwin linker oddness. __mf_register() should be callable explicitly from C code. The pass55 FAILs may be a varasm problem. I'd look at the intermediate assembler code and work backward. The pass40 FAILs look to me like they shouldn't happen. This is the multithreaded test that prints out a few numbers to validate the run. Maybe there is a CR/LF problem in the test case or the dejagnu driver? Overall, it looks close, though the number of PASSes are inflated somewhat by crediting merely successful compilation. The probable malloc interception problem has to be solved, and should make most of the failures go away. That's what I would look at next. - FChE
