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

[Lassi Tuura]

Hi,

> 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 :-)

Regards,
Lassi