From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21272 invoked by alias); 10 Apr 2006 17:47:40 -0000 Received: (qmail 21263 invoked by uid 22791); 10 Apr 2006 17:47:39 -0000 X-Spam-Check-By: sourceware.org Received: from mail.artimi.com (HELO mail.artimi.com) (217.40.213.68) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Apr 2006 17:47:37 +0000 Received: from mail.artimi.com ([192.168.1.3]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 18:47:34 +0100 Received: from rainbow ([192.168.1.165]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 18:47:34 +0100 From: "Dave Korn" To: "'Daniel Jacobowitz'" , Subject: RE: Cygwin GDB crashes from cvs - solib Date: Mon, 10 Apr 2006 18:02:00 -0000 Message-ID: <01a301c65cc6$d9023b80$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20060410172116.GA27907@nevyn.them.org> 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-04/txt/msg00119.txt.bz2 On 10 April 2006 18:21, Daniel Jacobowitz wrote: > Currently win32-nat.c sets in_dynsym_resolve_code and open_symbol_file > to NULL. The latter doesn't normally get called, but when it does, > it is called unconditionally; the former is called by "step". Should > win32-nat provide dummy functions or should the call sites check? Anyone > have an opinion? Well, IIUIC, we have various target vectors of different kinds throughout gcc binutils and gdb, and in every case that I can bring to mind off the top of my head, there's no requirement that every single entry has to be initialised, and a NULL entry indicates 'target does not have capability'. So from that point of view, ISTM that no call site should blindly jump through a target vector pointer without first checking that it is non-NULL, unless it already 'knows' by some other means that the current target /has/ to have the capability in question (in which case if the pointer is NULL it's a programming bug because the information in the target vector must not be semantically self-consistent). IASTM that if we start requiring all function-pointers in target vectors to be filled out with a pointer to a dummy function if there is no real function for the target, we lose the ability to test if the target has the given capability, and it would, in time, lead to people being tempted to write really ugly code such as:- if (current_target_so_ops->open_symbol_file == &dummy_open_symbol_file_stub) ... assume we don't have the capability ... else ... assume we do ... which wouldn't be a good thing IMO. However that's a generic POV on the general issue. Cgf will probably have a relevant opinion about this particular problem since he's been paying some attention to the win32 native solib stuff lately and I would defer to his judgement on this one. cheers, DaveK -- Can't think of a witty .sigline today....