Petr Machata <[email protected]> writes: > Dima Kogan <[email protected]> writes: > >>> We could actually store vectors in the hash table directly. >> >> The reason I did it this way was to reduce the memory inefficiency of >> the hash table. [...] Still want this change? > > That's a good point. I'm not decided one way or another, so let's keep > it the way you wrote it.
ok >> In any case, the patch seems to work, but I'd be more comfortable if the >> test suite told me it was good. I see the same test/suite failures >> before and after, some non-deterministic. Do you know which tests >> specifically are good to look at for a change like this? > > There are two tests in filters.exp that test specifically the -l stuff, > i.e. this sort of export list handling thing. OK. That test passes. I really should write a test for the DWARF code. I'll do that when I finish tying the loose ends. > Non-determinism in ltrace has always been a problem. It used to be much > worse, but there might still be latent bugs, or bugs that the kernels > other than those that I test on expose. What's you configuration, and > what failures are you seeing? I didn't take good notes, so this is incomplete, sorry. I was seeing the trace-irelative.exp test get into an infinite loop. ltrace was running until I killed it. The ltrace command was ./ltrace -L -x xyz /tmp/pie-yjtNlTxFte Running that same command with that same executable later worked just fine. There was some log file that was being generated that had 200MB of the same error repeated on every line. Something about an illegal or duplicated breakpoint; don't exactly remember, sorry. Re-running the test suite didn't show this problem. By the way, how much of the suite is supposed to pass normally? I always see some failures and a segfault. The configuration is Debian/sid on amd64; nothing noteworthy. > OK, so I tried to merge and do a test build, and am now getting this: > > <errors> I just pushed a patch. You were using an older gcc than me, and it's more picky. Before this patch I successfully tested with gcc 4.9. After, gcc 4.6 works too. I also just discovered that this new symbol aliasing code works with 'ltrace -l', but not any of the other filtering options. I'll take a look when i have time; hopefully by next week. dima _______________________________________________ Ltrace-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/ltrace-devel
