From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4064 invoked by alias); 1 May 2003 22:48:31 -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 4055 invoked from network); 1 May 2003 22:48:30 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 1 May 2003 22:48:30 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0545B2B2F; Thu, 1 May 2003 18:48:28 -0400 (EDT) Message-ID: <3EB1A43B.1040704@redhat.com> Date: Thu, 01 May 2003 22:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Evans Cc: gdb@sources.redhat.com Subject: Re: Inferior function call command set References: <3EB16A02.9080904@redhat.com> <16049.36280.775609.622335@casey.transmeta.com> <3EB1916D.7020102@redhat.com> <16049.38488.94378.161876@casey.transmeta.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00005.txt.bz2 > Andrew Cagney writes: > > > Out of curiousity, is there any need to have a runtime choice? > > > > Entry point in ROM, non 1:1 code/stack, ... > > Apologies, still confused. > [having spent the last few days buried in the guts of > hand-called-function support such things are very much on my > mind these days] > > How does having an entry point in ROM affect things? > It appears to me that all AT_ENTRY_POINT does is use the entry point > address as a magic number that will "never appear" in user code. > [thus if the callee is returning to it you know you're back in the "stub"] GDB tries to insert a breakpoint at that address (that doesn't work when it is in a ROM :-) Looking at the MIPS, it turned out to also not work very well when the entry point couldn't be found. > In my port I added the ability for the user to override > CALL_DUMMY_ADDRESS since the entry point is ambiguous/unspecified. > [THAT would be a very welcome addition to the mainline code. :-)] > Pproviding both AT_ENTRY_POINT and ON_STACK is _far_ more effort than > providing the ability to override what gdb uses for CALL_DUMMY_ADDRESS. > Perhaps what I should have done is just hardwire it to 42. 1/2 :-). That isn't true. For an up-to-date architecture, assuming the stack is executable(1), there should be zero change. In fact, given problems with finding the entry point address, on-stack is technically a better choice (although a quick reality-check will stop that change dead). The d10v's tweak and the retention of entry_point_address, stem from it being a true harvard architecture. A survey of architectures explicitly setting call_dummy_address reveals: alpha: does something slightly weird (that may now be redundant) avr: wrapped entry_point_address m68hc11: wrapped entry_point_address mips: wrapped entry_point_address, but with a hack for ROMs made redundant by ``set call breakpoint-location on-stack'' sparc: depending on a compile time option, uses either entry_point_address or the stack so CALL_DUMMY_ADDRESS can/should probably be wired to entry_point_address. > No claim is made that there isn't a need for the runtime > stack/entry-point choice. But I still don't understand the need for it. > [Not that anyone has to spend time clearing up my understanding of course; > but if it's not that much effort, or if other people are also curious ...] > > > An addition to the testsuite is implicit. Andrew (1) Someone needs to get this working when the stack isn't executable. The inferior would stop with a sigseg instead of sigtrap.