Re: frame unwinding patches

2017-04-03 Thread Jan Kratochvil
On Mon, 03 Apr 2017 11:00:03 +0200, Milian Wolff wrote:
> I just got a report from a colleague. As-is, elfutils would fail to unwind 
> from the following location in his application:
> 
> 0x1137ca4
> 
> With the x86_64 patch applied, he got a proper backtrace:

S/he has something wrong with the compiler.  With -fasynchronous-unwind-tables
frame pointer unwinding is never needed
and gcc defaults to -fasynchronous-unwind-tables on x86_64.

This is why I haven't implemented it originally as it only paper overs the
real problem and it leads to unreliable backtraces in longterm.


Jan


Re: frame unwinding patches

2017-04-04 Thread Jan Kratochvil
On Tue, 04 Apr 2017 09:40:06 +0200, Milian Wolff wrote:
> - In the example above, the address points into libnvidia-glcore.so and as 
> such not compiled by my colleague but rather provided by NVidia as a binary 
> blob. When you only got a binary blob and have to make do with it, you cannot 
> tell people to "just fix the compiler invocation".

This is their problem they support a vendor who cripples usage of their
products.  There is also Intel and AMD.


> - Some JIT compilers, like QV4, actually embed frame pointers into their 
> dynamic code, but do not go the extra mile for generating DWARF data or 
> asynchronous unwind tables. That is another case where the patches by Ulf 
> excel and make elfutils much more useful.

In such case elfutils could provide some workaround with a new eu-stack option:
--please-workaround-a-completely-broken-compiler-i-still-have-not-fixed
:-)


Jan