From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: Michal Ludvig <mludvig@suse.cz>,
Elena Zannoni <ezannoni@redhat.com>,
GDB Patches <gdb-patches@sources.redhat.com>
Subject: Re: PING: [RFA] Runtime Dwarf2 CFI engine cleanup
Date: Wed, 26 Feb 2003 18:36:00 -0000 [thread overview]
Message-ID: <20030226183555.GA16345@nevyn.them.org> (raw)
In-Reply-To: <3E5D05F9.6050605@redhat.com>
On Wed, Feb 26, 2003 at 01:22:49PM -0500, Andrew Cagney wrote:
> >
> >
> >I don't think that the way you're selecting objfiles to unload is ideal
> >- you're duplicating logic from objfile_purge_solibs. We need a more
> >general hook to free objfile-specific information. However, I believe
> >that can be addressed separately, and this will definitely fix some
> >crashes as-is and not introduce any new ones.
> >
> >I don't have any problem with linking dwarf2cfi.o in for all targets.
> >Let's sit on this for another day and see if anyone else objects, and
> >then you can commit it.
>
> A quick look at the bigger picture reveals:
>
> - the underlying code needs to be fixed before it is linked into all
> targets.
Why? The code can be fixed as it is activated for other targets;
linking and use aren't the same thing. I'd even call this the first
step in fixing it - doesn't break anything and makes it easier for
other targets to test it.
> - if it needs to be modified of changes in another part of gdb then it
> should use an observer. It should not introduce another hack.
>
> You'll note that Joel and I are currently working through this. Yes it
> means that the posted patch doesn't go in. It also means that GDB is
> that bit more (not less) maintainable.
OK, if that's your preference, Michal please do not check in this
patch. I think it's a bit silly to reject a patch which fixes a
"break; run; run" segfault on this basis, especially one two months
or more old, though.
This is one of the two major issues I know about that are forcing
Michal to do x86-64 development on 5.3 instead of HEAD. I applaud your
vision in preserving future maintainability; I'm tired of that vision
interfering with having a working GDB.
> >You made a line in Makefile.in too wide; please fix that before you
> >check it in.
> >
> >[List: my assumption in approving this is that the dwarf2cfi support is
> >not part of the dwarf2 reader, so I'm not stepping on anyone's toes.
> >If you disagree, please tell me so.]
>
> Puzzled expression.
This is the problem with vague lines of authority. It's not always
clear who can approve a patch even to people who do the approving. I'm
tired of exercising what seems to be pretty clear authority to approve
something and getting prickly mail from someone else overturning my
decision.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-02-26 18:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-06 12:55 Michal Ludvig
2003-02-03 16:23 ` Elena Zannoni
2003-02-10 12:30 ` Michal Ludvig
2003-02-26 15:35 ` PING: " Michal Ludvig
2003-02-26 15:47 ` Daniel Jacobowitz
2003-02-26 18:20 ` Andrew Cagney
2003-02-26 18:36 ` Daniel Jacobowitz [this message]
2003-02-26 19:32 ` Andrew Cagney
2003-02-26 19:38 ` Daniel Jacobowitz
2003-02-27 8:14 ` Michal Ludvig
2003-02-27 10:15 ` Michal Ludvig
2003-02-27 14:17 ` Daniel Jacobowitz
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=20030226183555.GA16345@nevyn.them.org \
--to=drow@mvista.com \
--cc=ac131313@redhat.com \
--cc=ezannoni@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