From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20421 invoked by alias); 22 Apr 2003 16:40:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20408 invoked from network); 22 Apr 2003 16:40:49 -0000 Received: from unknown (HELO mailhub.lss.emc.com) (168.159.2.8) by sources.redhat.com with SMTP; 22 Apr 2003 16:40:49 -0000 Received: from emc.com (lul1179.lss.emc.com [168.159.33.179]) by mailhub.lss.emc.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h3MGelj05733 for ; Tue, 22 Apr 2003 12:40:47 -0400 (EDT) Message-Id: <200304221640.h3MGelj05733@mailhub.lss.emc.com> To: gdb@sources.redhat.com Subject: macros, debug information, and parse_macro_definition Date: Tue, 22 Apr 2003 16:40:00 -0000 From: David Taylor X-SW-Source: 2003-04/txt/msg00245.txt.bz2 One of my projects at work is to do the necessary gcc and gdb work to allow users of sgdb (our GUI on top of GDB) to do macro expansion. Now, we use ELF/STABS, not ELF/DWARF... The encoding of macros that I have chosen is very very similar to the DWARF-2 encoding. In particular, the string is the same. (I see no reason to invent a new encoding.) As a result, at some point I will need to call a function which will either be identical to or 99% identical to parse_macro_definition. So, I'd like to propose that the function parse_macro_definition be made non static and that it and its support functions (copy_string, dwarf2_macro_malformed_definition_complaint, consume_improper_spaces -- all three of which are called *ONLY* by parse_macro_defintion) be moved to another file -- since they are not DWARF specific anymore. Any objections? File name? My inclination is to move them to macrotab.c since the function parse_macro_defintion calls functions within that file and can be thought of as a thin veneer above the functions macro_define_object and macro_define_function. Comments? David -- David Taylor dtaylor@emc.com