From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17837 invoked by alias); 9 Jul 2002 14:50:14 -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 17822 invoked from network); 9 Jul 2002 14:50:13 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 9 Jul 2002 14:50:13 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DB5D13CC5; Tue, 9 Jul 2002 10:50:09 -0400 (EDT) Message-ID: <3D2AF821.4090407@ges.redhat.com> Date: Tue, 09 Jul 2002 08:07:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Ludvig Cc: GDB Patches Subject: Re: [RFA] struct context moved References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00148.txt.bz2 >> Michael, >> >> I don't understand the rationale behind this. >> >> As a general trend, frame.h / struct frame is becomming increasingly >> opaque. I don't see a reason for moving dwarf2cfi specific stuff into >> frame.h. > > > Because we have > struct context *context; > in the declaration of "struct frame_info", I thought it was logical to > declare "struct context" in the same file. Otherwise, when debugging gdb > itself, I'm getting "incomplete type" message when examining the content > of struct frame_info. AFAIK it doesn't increase the size of the code, it > just gives to debugger the appropriate information about the type of > the structure. Ah! GDB is going in the direction of reducing the information visible in header files. ``struct gdbarch'', ``struct cmd_list_element'' and ``struct regcache'', for instance, are all opaque. Consequently, and very likely, ``struct frame_info'' will eventually become opaque. This approach puts very strong controls over how an object can be accessed. In the past GDB has relied on convention (macros) and code review as a way of ensuring this this is followed. Unfortunatly, as an examination of the code reveals, this has proven unreliable. As a very up-to-date example of the problem, consider the fixes Martin Hunt recently committed (added cmd_func()). GDB, for some time has been doing the very non-portable equivalent of: void f (int, float); (void (*)(int, float, void *)) f (1, 1.0, &foo); (assming I've got my C right :-) This was fixed in core GDB, Ufortunatly, because Insight (which uses GDB) was still accessing ``struct cmd_list_element'' internals, it was missed, and that lead to the unintentional introduction of a core dump. If the ``struct cmd_list_element'' had always been opaque, the internals change needed to fix this could have been implemented more robustly - the probably of the changes causing insight to crash would have been significantly reduced. Anyway, I'm some what puzzled by your problem. I suspect a stabs vs dwarf2 thing :-( When I debug, I have no problems displaying things like ``struct gdbarch'' which is opaque. The only other wild guess is to add the opaque declaration of ``struct context;'' to the top of "frame.h"?? enjoy, Andrew