From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11913 invoked by alias); 27 Aug 2002 00:28:56 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11904 invoked from network); 27 Aug 2002 00:28:56 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 27 Aug 2002 00:28:56 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA08939; Mon, 26 Aug 2002 17:22:00 -0700 (PDT) Message-ID: <3D6AC7C4.41BD8135@redhat.com> Date: Mon, 26 Aug 2002 17:50:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Andrew Cagney CC: Kevin Buettner , gdb-patches@sources.redhat.com Subject: Re: [RFA] Generic solution for store_struct_address References: <3D644ACA.3626BF8F@redhat.com> <1020826223151.ZM32716@localhost.localdomain> <3D6AB26F.10003@ges.redhat.com> <3D6AB358.F7E7D1FD@redhat.com> <3D6ABFA1.6010407@ges.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00879.txt.bz2 Andrew Cagney wrote: > > > Andrew Cagney wrote: > > > >> > > > >> > On Aug 21, 7:22pm, Michael Snyder wrote: > >> > > >> > > > > >> >> Kevin, would you by any chance be in a position to test it on ia64 > >> >> and/or > >> >> rs6000? > > > >> > > >> > > >> > Sure, I'll give it a spin... > > > >> > >> Just FYI, given the thread: > >> http://sources.redhat.com/ml/gdb-patches/2002-08/msg00674.html > >> I'm assuming that this patch is dropped. > > > > > > Why? I didn't drop it. You commented that using generic dummy > > frames was a better solution, but it remains true that some > > targets do not use generic dummy frames, and I'm not sure that > > all targets can use them. > > You mean: > > >> Adding such a field to the generic dummy frame is a good idea -- > >> but some architectures don't use the generic dummy frames. > > > That can be fixed by converting the architecture to generic dummy frames :-) > > That is a side issue --- anyone fixing a problem need only get it > working with targets using generic dummy frames. Any other target > should first be converted to generic dummy frames anyway. That may or may not be possible. > Anyway, summarizing posts such as: > > http://sources.redhat.com/ml/gdb-patches/2002-08/msg00688.html > http://sources.redhat.com/ml/gdb-patches/2002-08/msg00705.html > > > As far as I know, there are two cases: > > > > 1. a normal function forced to return: > > (gdb) break foo > > (gdb) finish > > Your patch does not, and cannot fix this case. I know that. It does fix case 2, and that's an improvement. > > 2. an inferior function call: > > (gdb) print foo() > > Your patch fixes this case. However, it is far easier to replace the > infrun.c code block: > > > * Figure out the value returned by the function. */ > > /* elz: I defined this new macro for the hppa architecture only. > > this gives us a way to get the value returned by the function from the stack, > > at the same address we told the function to put it. > > We cannot assume on the pa that r28 still contains the address of the returned > > structure. Usually this will be overwritten by the callee. > > I don't know about other architectures, so I defined this macro > > */ > > > > #ifdef VALUE_RETURNED_FROM_STACK > > if (struct_return) > > { > > do_cleanups (retbuf_cleanup); > > return VALUE_RETURNED_FROM_STACK (value_type, struct_addr); > > } > > #endif > > With the corresponding code lifted from HP/UX. Andrew, this approach has the same short-coming as the approach that you rejected when I tried to use it last week. It has no stack. It will not handle nested target function calls, because this part of gdb is not recursive. The patch that I am submitting here does not have that problem -- it keeps nested return addresses in a stack.