From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3363 invoked by alias); 9 Oct 2003 20:36: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 3355 invoked from network); 9 Oct 2003 20:36:50 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 9 Oct 2003 20:36:50 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3A4D12B89; Thu, 9 Oct 2003 16:36:48 -0400 (EDT) Message-ID: <3F85C6E0.3060704@redhat.com> Date: Thu, 09 Oct 2003 20:36:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: target_op(..) -> target_op(target, ...) obvious References: <3F855EFF.9080300@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00166.txt.bz2 > Andrew Cagney writes: > >> As part of the on-going OO of GDB, the "target vector" is one of the >> next things up for treatment. I'd like to be sure that everyones ok >> with the mechanical transformatioin: >> >> target_OP (...) -> taget_OP (target, ...) >> >> being considered "fairly obvious" (post patch, give it a few days, >> commit patch). Pushing the target around is going to involve touching >> files across maintenance boundraries. > > > So, in this patch, the calls would all pass a pointer to the global > variable 'current_target', right? Or would it also include changes to > functions' interfaces to pass the target around explicitly? "yes". Just like regcache, gdbarch, and frame, it would start out using current_gdbarch but then, over time evolve, to more correctly pass explicit parameters (be that frame, thread, regcache, or target). Oh, "this patch" doesn't exist. The intent is for this, again just like the other changes, to be rolled out over comming months. Oh, one motivation for me starting process is that it will let me parameterize CONVERT_FROM_FUNC_PTR_ADDR with an explicit target and that will in turn let me fix the entry-point problem you encountered with PPC64 GNU/Linux. Andrew