From: Andrew Cagney <cagney@gnu.org>
To: Daniel Jacobowitz <drow@false.org>
Cc: Eli Zaretskii <eliz@elta.co.il>,
gdb@sources.redhat.com, mec.gnu@mindspring.com
Subject: Re: Branch created for inter-compilation-unit references
Date: Thu, 26 Feb 2004 20:19:00 -0000 [thread overview]
Message-ID: <403E54DA.8050403@gnu.org> (raw)
In-Reply-To: <20040226192841.GA1005@nevyn.them.org>
> On Thu, Feb 26, 2004 at 02:24:46PM -0500, Andrew Cagney wrote:
>
>>>> >On Thu, Feb 26, 2004 at 08:30:56AM +0200, Eli Zaretskii wrote:
>>>> >
>>>
>>>>>> >>>It's not more important in general, but since we are preparing to cut
>>>>>> >>>the 6.1 branch in a few days, DW_OP_piece might be a good thing to do
>>>>>> >>>now, while delaying intercu-branch merge till after the release.
>>>>>> >>>It's a question of timing, not of an abstract importance.
>>>
>>>> >
>>>> >
>>>> >Then both you and Andrew underestimate the intrusiveness of DW_OP_piece
>>>> >support.
>>
>>>
>>> (I can't speak for Elena) I think I've got a pretty good feel for how
>>> much work is involved in finishing (rather than prototyping) something
>>> like this. Thats why I'm making noises about a DW_OP_piece hack for 6.1.
>
>
> I haven't heard any of these noises? In any case I don't think it's a
> particularly good idea, unless all you mean is handling the resulting
> error() call so that it doesn't abort symbol reading.
Lets say hints with others making various noises
http://sources.redhat.com/ml/gdb/2004-02/msg00170.html
If we don't do something, how useful will GDB 6.1 be when GCC 3.4 is
released? Spending resources on adding ICU to the branch certainly
won't fix that problem, sigh.
I'm thinking of something that at least stops GDB falling on its sword
when this happens.
Andrew
next prev parent reply other threads:[~2004-02-26 20:19 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-25 3:51 Michael Elizabeth Chastain
2004-02-25 5:12 ` Andrew Cagney
2004-02-25 16:10 ` Daniel Berlin
2004-02-25 17:01 ` Andrew Cagney
2004-02-25 17:07 ` Daniel Berlin
2004-02-25 18:50 ` Andrew Cagney
2004-02-25 18:53 ` Daniel Berlin
2004-02-25 19:48 ` Andrew Cagney
2004-02-26 5:48 ` Eli Zaretskii
2004-02-26 6:06 ` Daniel Berlin
2004-02-26 6:31 ` Eli Zaretskii
2004-02-26 15:05 ` Daniel Jacobowitz
2004-02-26 16:19 ` Elena Zannoni
2004-02-26 16:25 ` Daniel Jacobowitz
2004-02-26 16:36 ` Elena Zannoni
2004-02-26 16:54 ` Daniel Jacobowitz
2004-02-26 19:01 ` Eli Zaretskii
2004-02-26 19:10 ` Eli Zaretskii
2004-02-26 19:24 ` Andrew Cagney
2004-02-26 19:28 ` Daniel Jacobowitz
2004-02-26 20:19 ` Andrew Cagney [this message]
2004-02-26 5:48 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2004-02-21 20:08 Daniel Jacobowitz
2004-02-25 0:18 ` Daniel Jacobowitz
2004-02-25 0:35 ` Andrew Cagney
2004-02-25 1:29 ` Daniel Jacobowitz
2004-02-25 2:23 ` Andrew Cagney
2004-02-25 2:27 ` Daniel Jacobowitz
2004-02-25 3:17 ` Andrew Cagney
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=403E54DA.8050403@gnu.org \
--to=cagney@gnu.org \
--cc=drow@false.org \
--cc=eliz@elta.co.il \
--cc=gdb@sources.redhat.com \
--cc=mec.gnu@mindspring.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