From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24016 invoked by alias); 10 Feb 2002 20:09:52 -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 23616 invoked from network); 10 Feb 2002 20:09:44 -0000 Received: from unknown (HELO localhost.redhat.com) (24.114.26.18) by sources.redhat.com with SMTP; 10 Feb 2002 20:09:44 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D89D33C83; Sun, 10 Feb 2002 15:09:40 -0500 (EST) Message-ID: <3C66D384.5080102@cygnus.com> Date: Sun, 10 Feb 2002 12:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: Richard.Earnshaw@arm.com Cc: gdb@sources.redhat.com Subject: Re: multi-arch and CALL_DUMMY_BREAKPOINT_OFFSET References: <200202081134.LAA07778@cam-mail2.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00173.txt.bz2 > I guess I'm going to find several things like this... > Well it appears that in a multi-arch gdb (even at level 1), > CALL_DUMMY_BREAKPOINT_OFFSET can only be a constant for any particular > architecture. This is a problem, because on the ARM it is currently a > function that returns one of two values depending on whether the > call-dummy stub has to be ARM code or Thumb code. Note that both types of > code can exist within a single application and it is not always safe to > assume that every function is interworking safe. Oops :-( People keep finding things I thought would be constant but are not. > I guess I could re-write the whole of the call-dummy stuff so that > appropriate breakpoints are built in, but that is certainly going to be > non-trivial. > > Any suggestions? Can I diddle with the gdbarch setting dynamically -- eg > by calling gdbarch_set_call_dummy_breakpoint_offset() from within > arm_fix_call_dummy()? It's quite gross, but it might work. Two suggestions: Replace CALL_DUMMY_BREAKPOINT_OFFSET and CALL_DUMMY_BREAKPOINT_OFFSET_P with a predicate function (``F:'')? The predicate mechanism was only added recently. I have a feeling that while this looks good, it isn't as easy as it seems :-( Introduce a new method (``f:'') that, for legacy code, uses CALL_DUMMY_BREAKPOINT_OFFSET? Deprecate (ARI / bug report) the old CALL_DUMMY_BREAKPOINT_OFFSET variable. > Long term it would probably be better to rewrite the call-dummy handling > to remove the covert variable that is used to communicate between the > various call-dummy stubs, but I'd rather not do that now. /* CALL_DUMMY is an array of words (REGISTER_SIZE), but each word is in host byte order. Before calling FIX_CALL_DUMMY, we byteswap it and remove any extra bytes which might exist because ULONGEST is bigger than REGISTER_SIZE. NOTE: This is pretty wierd, as the call dummy is actually a sequence of instructions. But CISC machines will have to pack the instructions into REGISTER_SIZE units (and so will RISC machines for which INSTRUCTION_SIZE is not REGISTER_SIZE). NOTE: This is pretty stupid. CALL_DUMMY should be in strict target byte order. */ You would not be alone. Andrew