From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16672 invoked by alias); 27 Jan 2006 18:25:41 -0000 Received: (qmail 16663 invoked by uid 22791); 27 Jan 2006 18:25:40 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Jan 2006 18:25:39 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-255-5.inter.net.il [83.130.255.5]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DLH75853 (AUTH halo1); Fri, 27 Jan 2006 20:25:36 +0200 (IST) Date: Fri, 27 Jan 2006 18:57:00 -0000 Message-Id: From: Eli Zaretskii To: gdb@sourceware.org In-reply-to: <20060127180429.GA15726@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 27 Jan 2006 13:04:29 -0500) Subject: Re: Using XML in GDB? Reply-to: Eli Zaretskii References: <20060126055744.GA29647@nevyn.them.org> <20060127180429.GA15726@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00312.txt.bz2 > Date: Fri, 27 Jan 2006 13:04:29 -0500 > From: Daniel Jacobowitz > > The proposal I sketched out in May is indeed simple. The bits with > "architecture-specific data" and "registers tags" are the only hints > that it may need to evolve in the future. However, there's a lot of > other things which GDB would like to know about targets, in an ideal > world. A great example that GDB wouldn't make use of today, but > could, is Andrew Stubbs' mention of memory maps paired with the recent > report of backtrace blowing up on uclinux. If we can receive the > memory map from the remote stub, we can absolutely guarantee that we > never send reads to outside of RAM when we wanted RAM access. Can we at least have a pipe-dream list of things we think GDB would ideally like to know about targets, and how structured each one of them is? > If we're going to do that, it would be a real shame not to consider > localization; most ARM system programmers can probably manage the > English names of the registers, but if we want to offer help text, > being able to provide it in Japanese is a big win. So that means > character encodings, and in turn that means we need to be somewhat > careful with the contents of descriptions. That part is something I never understood in your reasoning: XML does not do anything special to allow UTF-8, nor help you deal with the resulting non-ASCII text on the GDB side. If the underlying libc supports UTF-8, you have that now; if it doesn't, you won't be better off even if the target speaks XML. > The biggest win of XML, for me, is that there are standard answers to > all of these problems and standard tools for editing and > checking XML files. Is XML the only widely used standard that supports what we want?