From: Andrew Cagney <ac131313@redhat.com>
To: Michal Ludvig <mludvig@suse.cz>
Cc: GDB Patches <gdb-patches@sources.redhat.com>
Subject: Re: [RFA] Artifical dwarf2 debug info
Date: Mon, 16 Dec 2002 09:25:00 -0000 [thread overview]
Message-ID: <3DFE0741.7020902@redhat.com> (raw)
In-Reply-To: <3DFBD14C.7090501@suse.cz>
> Hi all,
> this long patch provides a fix for a very annoying fact, that GDB on x86-64 can't do backtraces from hand-optimized assembler functions (that applies for example to glibc's memset, str*, etc as well as to syscall wrappers).
> This is caused by the lack of a valid debug_frame/eh_frame FDE entry for such a function (noone really writes .debug_frame section in his assembler code :-)
>
> My approach to fix this behaviour is based on the fortunate fact, that most of those affected glibc's functions don't touch the stack at all, so creating an artifical FDE for them is easy.
If I understand this correctly, you've created create dwarf2cfi info for
a function that has no such info. That way the dwarf2cfi code can
unwind a function that doesn't actually have CFI?
If that is the case then I don't think this is either necessary or
correct. A `struct frame_info' allows frame specific unwind functions -
at present only dummy-frame and saved-regs-frame versions are
implemented, however the next ones to implement are cfi-frame (unwind
using CFI info) and regs-frame (unwind using the register cache).
For your problem, wouldn't it be better to, instead of creating fake CFI
info, implement custom frame unwind functions that handle your case?
Andrew
next prev parent reply other threads:[~2002-12-16 17:03 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-14 17:31 Michal Ludvig
2002-12-14 22:53 ` Eli Zaretskii
2002-12-15 11:03 ` Daniel Jacobowitz
2002-12-16 7:28 ` Michal Ludvig
2002-12-16 7:49 ` Daniel Jacobowitz
2002-12-16 9:27 ` Michal Ludvig
2002-12-16 9:54 ` Daniel Jacobowitz
2002-12-16 10:38 ` Eli Zaretskii
2002-12-20 8:43 ` Michal Ludvig
2002-12-20 10:51 ` Eli Zaretskii
2002-12-16 9:25 ` Andrew Cagney [this message]
2002-12-16 9:40 ` Daniel Jacobowitz
2002-12-16 10:04 ` Andrew Cagney
2002-12-16 10:17 ` Daniel Jacobowitz
2002-12-16 10:56 ` Andrew Cagney
2002-12-16 11:13 ` Daniel Jacobowitz
2002-12-16 11:34 ` Andrew Cagney
2002-12-16 11:57 ` Daniel Jacobowitz
2002-12-16 12:10 ` Andrew Cagney
2002-12-16 12:42 ` Daniel Jacobowitz
2002-12-17 6:23 ` Michal Ludvig
2002-12-17 6:28 ` Andrew Cagney
2002-12-17 8:42 ` Daniel Jacobowitz
2002-12-18 4:39 ` Andrew Cagney
2002-12-18 10:05 ` Daniel Jacobowitz
2003-01-02 20:54 ` Andrew Cagney
2003-01-02 21:19 ` Daniel Jacobowitz
2003-01-02 23:05 ` Andrew Cagney
2003-01-02 23:27 ` Daniel Jacobowitz
2003-01-03 0:28 ` Andrew Cagney
2002-12-16 9:46 ` Michal Ludvig
2002-12-16 9:57 ` Andrew Cagney
2002-12-16 10:01 ` Michal Ludvig
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=3DFE0741.7020902@redhat.com \
--to=ac131313@redhat.com \
--cc=gdb-patches@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