This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: patch: fix stack unwind through uClibc syscall() on mips
- From: JÃn StanÄek <jan dot stancek at gmail dot com>
- To: JÃn StanÄek <jan dot stancek at gmail dot com>, gdb-patches at sourceware dot org
- Date: Tue, 6 Apr 2010 22:03:08 +0200
- Subject: Re: patch: fix stack unwind through uClibc syscall() on mips
- References: <737ad3551003271055o91a78i3f5ff305b927e441@mail.gmail.com> <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
>