From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21809 invoked by alias); 18 Mar 2002 18:45:52 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21685 invoked from network); 18 Mar 2002 18:45:35 -0000 Received: from unknown (HELO monkey.daikokuya.demon.co.uk) (158.152.184.26) by sources.redhat.com with SMTP; 18 Mar 2002 18:45:35 -0000 Received: from neil by monkey.daikokuya.demon.co.uk with local (Exim 3.35 #1 (Debian)) id 16n28L-0005PM-00; Mon, 18 Mar 2002 18:45:25 +0000 Date: Mon, 18 Mar 2002 10:45:00 -0000 From: Neil Booth To: Daniel Berlin Cc: Jim Blandy , gdb-patches@sources.redhat.com, gcc@gcc.gnu.org Subject: Re: RFC: C/C++ preprocessor macro support for GDB Message-ID: <20020318184525.GC19897@daikokuya.demon.co.uk> References: <20020318072916.GB14970@daikokuya.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-SW-Source: 2002-03/txt/msg00315.txt.bz2 Daniel Berlin wrote:- > Even if he didn't want to use libcpp, due to interface, ucpp would fit > well here too and is smaller/has no memory issues. UCPP was "designed to > be fast, with low memory consumption, and reusable as a lexer in other > projects". ucpp is quite nice, and implemented quite differently to cpplib. When Thomas wrote it, he was correct that it used a lot less memory than the pre-3.0 cpplib. If you recall, however, there was a silly bug of mine that led to memory not being freed, and macro expansion tended to consume ever more memory. This was fixed in 3.0, and I made further improvements to memory consumption in 3.1. I think it's fair to say that cpplib is now equal to ucpp, and in high-stress macro expansion outperforms it significantly memory-wise. [And uses less memory than all previous cpp implementations in GCC.] I think cpplib is also faster than ucpp, though that's not important for GDB. Zack and I hope to squeeze out more memory efficiency sometime in 3.2 by shrinking the size of cpp_token from 16 / 24 bytes to 12 / 16 bytes [32bit/64bit]. Since most of cpplib's memory use is storing macro expansions in tokenized form, this should help reduce memory consumption by at least another 10% I'd estimate. ucpp does not expand some macros the same way as cpplib. cpplib's expansion algorithm matches what was _intended_ by the subcommitte that standardized macro expansion, although it is debatable whether their use of English in the standardese is clear enough. [I was kindly sent a psuedo-code algorithm that they agreed to in 1989 by Dave Prosser, who took part in the standardization work. It was described in terms of macro hide sets. Oddly enough, the only commercial preprocessor that implements it perfectly appears to be SCO's 8-) cpplib instead uses a disabled macro stack with token marking, which is considerably more efficient, but achieves an identical result]. ucpp does not implement GCC's macro extensions, of course. We should have GCC and GDB agree perfectly on macro expansion, otherwise there is little point. Neil.