public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@chello.nl>
To: mludvig@suse.cz, ac131313@redhat.com
Cc: gdb@sources.redhat.com
Subject: Re: dwarf-frame.c question
Date: Thu, 29 May 2003 15:44:00 -0000	[thread overview]
Message-ID: <200305291544.h4TFi7aL031832@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <3ED381CB.5050207@suse.cz> (message from Michal Ludvig on Tue, 27 May 2003 17:18:35 +0200)

   Date: Tue, 27 May 2003 17:18:35 +0200
   From: Michal Ludvig <mludvig@suse.cz>

   Hi Mark,

   why do you decrement unwound PC in dwarf_frame_cache() before using it?

The unwound PC is the return address, i.e. the instruction that will
be executed when the function returns.  This is the instruction after
the call instruction.  The problem is that if the call instruction is
the last instruction of a function, the return address might point to
the next function:

foo:
   ...
   call abort

bar:
   push %ebp
   mov %esp, %ebp
   ...

That's why the GCC unwinder does the same thing.  Note that the
decrementing the PC is wrong for "interrupt frames", which is why the
if-statement is there in the code fragment you cite:

   dwarf-frame.c:
   478       /* Unwind the PC.  */
   479       fs->pc = frame_pc_unwind (next_frame);
   480       if (get_frame_type (next_frame) == NORMAL_FRAME
   481           && frame_relative_level (next_frame) >= 0)
   482         fs->pc--;

   This makes a problem for a signal trampoline.
   If it is sitting on addresses say 0x40000140-0x40000150, the return 
   address from signal handler is 0x40000140, but dwarf_frame_cache() says 
   it is 0x4000013f and couldn't find it's CFI...

Do you have signal trampolnes with CFI?  If the CFI is hand-generated,
you should probably "cheat" by adding a nop before the trampoline and
include it in the address range of the FDE (see the
arch/i386/kernel/vsyscall-sigreturn.S in the Linux kernel sources).

   This has a tragic consequence few lines below were you look for FDE but 
   don't check if you find one. If you don't, line 488 segfaults.
   484       /* Find the correct FDE.  */
   485       fde = dwarf_frame_find_fde (&fs->pc);

Hmm, a gdb_assert() is in order here.

   487       /* Extract any interesting information from the CIE.  */
   488       fs->data_align = fde->cie->data_alignment_factor;
   489       fs->code_align = fde->cie->code_alignment_factor;
   490       fs->retaddr_column = fde->cie->return_address_register;

   The problem is, that dwarf_frame_p() looks for the real return address 
   and says that there is a debug info and sets unwinder to use dwarf2 
   methods for this farme.

Hmm, it should do something similar as dwarf_frame_cache().

   But the in unwinder itself in dwarf_frame_cache() looks for the 
   decreased one and of course doesn't find it.

That defenitely is a bug.  It isn't immediately obvious to me how to
solve this :-(.  Andrew, it seems that we should tweak the frame code
to make sure that frame_unwind_by_pc is always passed a PC *within* the
function.

Mark

  reply	other threads:[~2003-05-29 15:44 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-27 15:19 Michal Ludvig
2003-05-29 15:44 ` Mark Kettenis [this message]
2003-05-29 19:54   ` Andrew Cagney
2003-05-29 22:22     ` Mark Kettenis
2003-05-29 22:43       ` Michal Ludvig
2003-05-29 23:13       ` Andrew Cagney
2003-05-30  1:34         ` Daniel Jacobowitz
2003-05-30 20:21         ` Jim Blandy
2003-05-30 20:32           ` Andrew Cagney
2003-06-03  0:04             ` Jim Blandy
2003-06-03  5:47               ` Richard Henderson
2003-06-03  6:32                 ` Jim Blandy
2003-06-03 15:58                   ` Richard Henderson
2003-06-03 17:38                     ` Richard Henderson
2003-06-03 20:12                   ` Alexandre Oliva
2003-05-30 20:44           ` Alexandre Oliva
2003-05-30 20:21         ` Jim Blandy
2003-06-01  5:59 Richard Henderson
2003-06-01 10:00 ` Mark Kettenis
2003-06-02 20:34   ` Richard Henderson

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=200305291544.h4TFi7aL031832@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=ac131313@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=mludvig@suse.cz \
    /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).