From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Berlin <dan@www.cgsoftware.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: GDBARCH vs frame vs stacks
Date: Tue, 15 May 2001 11:52:00 -0000 [thread overview]
Message-ID: <3B017AE9.5060106@cygnus.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0105141729090.7473-100000@www.cgsoftware.com>
> Rather than dumping the problem on gdbarch, I think the thing to do is
>> review the way that core-gdb interacts with a frame and determine an
>> interaction model that accomodates both existing abi and abi's based
>> around dwarf2 info. In doing this, the end result should be a good clean
>> understandable (and not dwarf2 centric) design.
>
>
> Sure. I just didn't want to resdesign the frame ATM, to be honest, because
> it would open up a can of worms since i'm sure everyone has *something*
> they want frames to be able to do, that they don't do now, and thus, i'd
> be getting myself into too much ATM. There was nothing dwarf2 specific
> about my current interjection into *_get_saved_register, in actuality. I
> had added a symbol file hook (well two) for getting and evaluating call frame
> info, and made the elf reader (which is where these hooks are acutally
> used) call through to dwarf2's getting and evaluating routines (because no
> other formats we currently support support it). All i had added to the
> actual *_get_saved_register routines was the code to get the objfile for
> the frame function, and call through to it's hook.
What I have in mind is rationalization of the frame object so that it
does less not more. To me the problem is that the frame abstraction is
confused - not suprising given it has evolved over time.
The recent proposals to sort out the register interface is an example.
It actually ends up with a smaller simpler interface.
Hopefully it is possible to look at the dwarf2 abstraction model and
find something that is common to both it and the other debug systems.
Andrew
prev parent reply other threads:[~2001-05-15 11:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-14 8:55 Andrew Cagney
2001-05-14 14:57 ` Daniel Berlin
2001-05-14 15:14 ` Daniel Berlin
2001-05-15 11:52 ` Andrew Cagney [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=3B017AE9.5060106@cygnus.com \
--to=ac131313@cygnus.com \
--cc=dan@www.cgsoftware.com \
--cc=gdb-patches@sourceware.cygnus.com \
/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