On Sat, 2013-12-21 at 22:33 +0100, Jan Kratochvil wrote:
> On Fri, 20 Dec 2013 15:23:54 +0100, Mark Wielaard wrote:
> > While playing with the new unwinder interfaces I noticed that I was
> > writing the same extra wrapper callbacks every time.
>
> Glad you agree the callbacks without lambda funct
While working on using the pid unwinder in ltrace I noticed it didn't
really play well with a process that might already be ptrace attached
to the thread under inspection. This patch solves that by detecting the
thread already is ptrace attached and making sure we don't detach it
ourselves in that
On Fri, 20 Dec 2013 15:23:54 +0100, Mark Wielaard wrote:
> While playing with the new unwinder interfaces I noticed that I was
> writing the same extra wrapper callbacks every time.
Glad you agree the callbacks without lambda functions are a pain. :-)
[...]
> --- a/libdwfl/libdwfl.h
> +++ b/libd
On PPC64 there are two DWARF registers numbers that can represent the
same register. If that register is the CIE return register then we only
want to set it once. The second setting will confuse the unwinder.
Signed-off-by: Mark Wielaard
---
libdwfl/ChangeLog | 5 +
libdwfl/frame_unwin
On Sat, 21 Dec 2013 19:44:28 +0100, Mark Wielaard wrote:
> On some architectures gcc might introduce some "padding instructions"
> at the end of the function (like on ppc64). So only assert we are at the
> last instruction of backtracegen if on x86_64 native. In theory the assert
> could even fail
On Sat, Dec 21, 2013 at 12:46:19PM -0500, Frank Ch. Eigler wrote:
> > Yeah, I think you are right, I overdid it because I was a little embarrassed
> > I had to count the brackets 6 times before seeing the bug even after it was
> > pointed out to me. Pushed the simplified version:
>
> Aw heck, at t
On some architectures gcc might introduce some "padding instructions"
at the end of the function (like on ppc64). So only assert we are at the
last instruction of backtracegen if on x86_64 native. In theory the assert
could even fail on that architectures, but in practice it doesn't and it
is a nic
Hi -
> Yeah, I think you are right, I overdid it because I was a little embarrassed
> I had to count the brackets 6 times before seeing the bug even after it was
> pointed out to me. Pushed the simplified version:
Aw heck, at that point, why not
...
int res = asprintf (&archive,
On Fri, Dec 20, 2013 at 03:09:28PM -0800, Roland McGrath wrote:
> Personally I'd like it better as a ?: in the initializer rather than an if
> (no repetition of "res ="). But I agree that putting the unlikely (... < 0)
> separate from the ... makes it easier to follow.
Yeah, I think you are right
