public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Ján Stanček" <jan.stancek@gmail.com>
To: "Ján Stanček" <jan.stancek@gmail.com>, gdb-patches@sourceware.org
Subject: Re: patch: fix stack unwind through uClibc syscall() on mips
Date: Tue, 06 Apr 2010 20:03:00 -0000	[thread overview]
Message-ID: <n2t737ad3551004061303sabf7a75p199eadee3d17ba76@mail.gmail.com> (raw)
In-Reply-To: <20100405155102.GA23667@caradoc.them.org>

On Mon, Apr 5, 2010 at 5:51 PM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> On Sat, Mar 27, 2010 at 06:55:18PM +0100, Ján Stanček wrote:
>> uClibc syscall() is macro which modifies stack before syscall
>> instruction, gdb is only looking at function prologue and misses the
>> stack modification made in syscall(). Because of this unwind doesn't
>> work. Attached is a patch, which is looking at actual $pc and $pc-4,
>> and in case of syscall it modifies $sp, so mip32_scan_prologue finds
>> correct values.
>>
>> Description of bug is also available here:
>> http://www.listware.net/201003/gnu-gdb/26893.html
>
> Have you considered just annotating the syscall routine with DWARF-2
> tables?  That's how GLIBC solves this problem.  And it doesn't take up
> any space in a stripped binary.

No, I haven't. I'm not sure I understand how this can be done. Also I
assume this wouldn't help with existing core files made with
unmodified uClibc.

>
> [Hmm, good wiki topic?]
>
> It looks like this patch detects the syscall instruction followed by a
> single instruction that adjusts sp.  It will break if the opposite
> SP adjustment was already found by the prologue analyzer.

Isn't the opposite SP adjustment found each time? The loop goes from
start_pc to current pc (syscall instruction), so the opposite SP
adjustment should be found. As I understand it, the register offsets
are saved using current SP:
set_reg_offset (gdbarch, this_cache, reg, sp + low_word);
and all SP adjustments don't really have any effect on these. SP
adjustments affect only frame_offset (this_cache->base).

>
> --
> Daniel Jacobowitz
> CodeSourcery
>

      reply	other threads:[~2010-04-06 20:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-27 17:55 Ján Stanček
2010-04-05 15:45 ` Joel Brobecker
2010-04-06 18:55   ` Ján Stanček
2010-04-07 17:11     ` Joel Brobecker
2010-04-05 15:51 ` Daniel Jacobowitz
2010-04-06 20:03   ` Ján Stanček [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=n2t737ad3551004061303sabf7a75p199eadee3d17ba76@mail.gmail.com \
    --to=jan.stancek@gmail.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).