On Mar 4, 2006, Daniel Jacobowitz wrote: > On Sat, Mar 04, 2006 at 09:01:43AM -0300, Alexandre Oliva wrote: >> > It's also good to have a few testcases, >> > but I don't completely understand the testcases :( >> >> You're not alone in that feeling, I assure you :-) > Like Mark, I am happier with the code than the testcases. In fact, > I'd rather not have the tests at all than have something quite > so overkill. Fair enough... Those tests uncovered a problem with the way our dwarf2 code identifies frames, though: it uses the function start address and the CFA to identify a stack frame, whereas it should use the PC and the CFA. In some corner cases, such as the one exercised by the i386 testcase, if you're on the second instruction of the region covered by the hand-generated unwind info and ask for a backtrace, GDB complains that the stack is corrupt, but the only problem is that the dwarf2 machinery gets confused by the same-CFA, same-function pair of stack frames. This is fixed in the revised patch below. > And you're not correct that older GCCs could run them > far enough to test; they'll fail to build because of the use of > __attribute__((cleanup)) Oops, indeed, sorry about that. The testcases must definitely be amended if they're to remain. Should they? > You ought to be able to test this much more simply, if you wire it > up to the bits in gdb.asm. But that wouldn't have caught errors in processing complex dwarf expressions, which the current testcases did in an older tree. > I'm sure it won't work for some platforms, and we'll have to add some > skips in the .exp file, but it ought to get enough of the current > ELF/dwarf platforms to be interesting, don't you think? Not sure... You talked about signal augmentations, but that's a different patch in a different thread. This one is about complex dwarf2 expressions involving newly-introduced encodings. I'm not sure how to encode such tests with gdb.asm, but I may look into it if dropping the tests in the following updated patch is not good enough.