[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] libunwind x86-64 optimisations?

From: Lassi Tuura
Subject: Re: [Libunwind-devel] libunwind x86-64 optimisations?
Date: Mon, 6 Jul 2009 18:20:55 +0200


Looks like you're lucky - _dl_debug_state is only one byte, but glibc
generally has padding before the next function.  Should work.

Yeah, there's plenty of padding at least on the platform I am looking at. I should be able to hook there.

I did run into functions that had non trivial CFA location; it wasn't
a straight register value but some sort of an expression. I'll do
more research to see what exactly happens in functions using alloca()
/ vla, and what the DWARF info looks like.

This could also be a dynamic stack realignment (for support of
vectorization).  I didn't think x86-64 needed that, though.

OK, in the libraries I looked there's basically only use of r{6,7} +/- offset as a CFA. There's tons of DW_CFA_def_cfa_offset{,_sf} use which I meant the CFA isn't just a simple register value but an expression. (There were exceptions for syscalls and longjmp, but I think I can live with those :-)

I made some tests with VLAs and alloca, and so far it seems the compiler always falls back to using a "traditional" frame pointer (cfa = rbp + offset; rsp movement for dynamic allocations). There were no complicated expressions beyond those mentioned above, which is good news. Does anyone know any real-world example where any reasonably widely use compiler (GCC, ICC, ...) will use some other scheme that those mentioned above?

OK so it looks like the strategy of caching CFA offsets might actually work :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]