From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26461 invoked by alias); 20 Oct 2006 18:03:45 -0000 Received: (qmail 26452 invoked by uid 22791); 20 Oct 2006 18:03:44 -0000 X-Spam-Check-By: sourceware.org Received: from heller.inter.net.il (HELO heller.inter.net.il) (192.114.186.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Oct 2006 18:03:39 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-33-81.inter.net.il [80.230.33.81]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id ATR09328 (AUTH halo1); Fri, 20 Oct 2006 19:03:21 +0200 (IST) Date: Fri, 20 Oct 2006 18:03:00 -0000 Message-Id: From: Eli Zaretskii To: Daniel Jacobowitz CC: andrew.stubbs@st.com, gdb-patches@sourceware.org In-reply-to: <20061020174648.GA4647@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 20 Oct 2006 13:46:48 -0400) Subject: Re: [PATCH] Don't give spurious warnings when using thread specific breakpoints Reply-to: Eli Zaretskii References: <452D0385.6010103@st.com> <20061011204525.GA9622@nevyn.them.org> <45361793.1020202@st.com> <20061018141419.GA7771@nevyn.them.org> <4536444C.9020709@st.com> <45374981.5080304@st.com> <20061020142933.GA28396@nevyn.them.org> <20061020174648.GA4647@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00257.txt.bz2 > Date: Fri, 20 Oct 2006 13:46:48 -0400 > From: Daniel Jacobowitz > Cc: andrew.stubbs@st.com, gdb-patches@sourceware.org > > > > We need to have different code branches, one each for each one of the > > possibilities, and each branch should have a format string for a full > > sentence that is produced by that branch. > > > > If there are too many such possible combinations, then the i18n > > comment should explain the context, as I mentioned elsewhere. (I'm > > quite sure we've been through a similar discussion a year or so ago, > > about another place where the code does similar things.) > > And I'm pretty sure we concluded there wasn't a reasonable way to do > this... perhaps my example wasn't good enough. No, we concluded that if there were no reasonable way of doing that, we should use an i18n comment to have the context explained in gdb.pot, where the translators will see it. Which is what I mentioned as a fallback above. > Note: breakpoints 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10 also set at pc 0x439ee0. > Breakpoint 11 at 0x439ee0 > > There can be an arbitrary number of elements. Yes, I understood that much. > It'd be easy to reduce the possibilities somewhat, by using "%d > (disabled)" and "%d (disabled) (thread %d)" and so forth. But I'm > stumped what to do about the comma separated list. How about rewriting the code so it'll produce something like Note: breakpoint(s) 1-9, 10-15, 21, 42 also set at pc 0x439ee0. ? Then we could have the variable list of breakpoint numbers produced as a string, and output that string with a format such as this: "Note: breakpoint(s) %s also set at pc 0x%x." Actually, this would work for i18n even if we don't produce ranges of numbers but a plain "1, 2, 3, 4, ..." list, but ranges would compress some overly-long lists. The `disabled' notification could be printed as a separate message. For example: Note: breakpoint(s) 1-9, 10-15, 21, 42 also set at pc 0x439ee0. Note: breakpoint(s) 3, 11, 21 are disabled. We could do something similar with "(thread %d)", for example produce a separate message for each thread. I think that the current format becomes quite unreadable anyway when too many "disabled" and "thread N" parts are produced. WDYT?