On Tue, Mar 13, 2012 at 5:11 AM, Konstantin Belousov <[email protected]> wrote:
>> * tests/test-coredump-unwind doesn't test anything right now. An >> actual test that fails if future commits break things would be great. >> This might require a test core dump file for every platform you care >> about. > I think it is requirement to generate a coredump on machine where the > testing is performed. You're right. I don't think coredump unwinding on another platform is supported. >> People working on other platforms: please verify that this works for >> you (or at least doesn't break anything). > It does break build. > Please look at http://people.freebsd.org/~kib/git/libunwind.git/ > branch coredump2, were I made it at least compilable for FreeBSD/i386 > and FreeBSD/amd64. > > The commit 52a8e2119d86a55218b8bf131f46a78fdac861dd is probably wrong, > I do not have Linux machine to test. Yes - it breaks Linux. I pulled everything up to dc9be1a into: git://github.com/adsharma/libunwind.git (coredump2) > > I am not sure how to test the functionality. The comments at the top of test-coredump-unwind might be useful. I recall getting some reasonable output in the last iteration of the patch. * * Run: * objdump -sx COREDUMP * eu-unstrip -n --core COREDUMP * figure out which segments in COREDUMP correspond to which mapped executable files * (binary and libraries), then supply them like this: * ./example-core-unwind COREDUMP 3:/bin/crashed_program 6:/lib/libc.so.6 [...] Denys: can you automate the objdump step or have the test figure out the right segment automatically? -Arun _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
