From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27670 invoked by alias); 10 Apr 2006 18:00:14 -0000 Received: (qmail 27661 invoked by uid 22791); 10 Apr 2006 18:00:13 -0000 X-Spam-Check-By: sourceware.org Received: from fios.cgf.cx (HELO cgf.cx) (71.248.179.247) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 10 Apr 2006 18:00:12 +0000 Received: by cgf.cx (Postfix, from userid 201) id 61E3D13C003; Mon, 10 Apr 2006 14:00:10 -0400 (EDT) Date: Mon, 10 Apr 2006 18:08:00 -0000 From: Christopher Faylor To: 'Daniel Jacobowitz' , gdb@sourceware.org, Dave Korn Subject: Re: Cygwin GDB crashes from cvs - solib Message-ID: <20060410180010.GC19752@trixie.casa.cgf.cx> Reply-To: gdb@sourceware.org Mail-Followup-To: 'Daniel Jacobowitz' , gdb@sourceware.org, Dave Korn References: <20060410172116.GA27907@nevyn.them.org> <01a301c65cc6$d9023b80$a501a8c0@CAM.ARTIMI.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01a301c65cc6$d9023b80$a501a8c0@CAM.ARTIMI.COM> User-Agent: Mutt/1.5.11 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/msg00120.txt.bz2 [reply-to set] On Mon, Apr 10, 2006 at 06:47:34PM +0100, Dave Korn wrote: >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. I don't think you really need my opinion on this. The above reasoning seems to me to be 100% correct. Whether win32-nat.c should add these two functions (or any others that may be missing) is really another problem entirely. cgf