[Top][All Lists]

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

Re: [Libunwind-devel] Port fasttrace to x86

From: Paul Pluzhnikov
Subject: Re: [Libunwind-devel] Port fasttrace to x86
Date: Fri, 11 Nov 2011 09:23:21 -0800

On Fri, Nov 11, 2011 at 4:40 AM, Lassi Tuura <address@hidden> wrote:
>> Attached patch almost entirely mechanically copies x86_64/Gtrace.c and
>> x86_64/Gstash_frame.c to x86.
> Nice, thanks for doing the port. It looks mostly fine to me, some notes
> below. We don't use 32-bit any more, so it kind of fell off my radar, and
> I don't really have an environment to even test these. I was mainly
> concerned there are too many real-life systems with poor signal stack
> annotations in x86 world, or some other simplifying assumptions broke.

FWIW, I have not yet tested this extensively on Google code either, but
I will be doing that this month.

Also, using e.g. Ubuntu 10.04 GCC (4.4.3-4ubuntu5), one needs to build
with -fasynchronous-unwind-tables to get the unwind info generated at all.

But the worst that would happen is that the fast trace will fail and fall
back to the slow trace, right?

Hmm, that's not what appears to happen though: I get _ULx86_tdep_trace
return 0, which does not trigger fall back to slow_trace.

Also, if I build with above GCC and CFLAGS = '-g -O0', then I get a crash
during fast trace ;-(

Given above problems, perhaps we should enable 32-bit fast trace under
configure --enable-fast-trace-for-x86 or some such?

> The notes:
> * There are a few instances of 'rbp', 'rsp', 'RBP', 'RSP' in comments in
> include/tdep-x86/libunwind_i.h and src/x86/Gtrace.c you might edit.


> * It seems you use LINUX_SC_EIP_OFF etc. I think this code is also used
> on FreeBSD, so I am not sure if there will be problems with that. Maybe
> Konstantin could confirm that for you?

The delta between LINUX_SC_EIP_OFF and LINUX_SC_EBP_OFF is the same as
for FREEBSD. And I planning to throw this away in the other patch.

But fixed anyway.

> * trace_lookup() could use uint32_t and 32-bit math on x86. Maybe it
> should be written to use unw_word_t in both, except for the hash
> multiplier constant.

Fixed for both.

> * The patch seems to omit Ltrace.c (but it's trivial...).


Paul Pluzhnikov

Attachment: libunwind-fasttrace-x86-20111111.txt
Description: Text document

reply via email to

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