From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3218 invoked by alias); 25 Apr 2002 02:30:37 -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 3199 invoked from network); 25 Apr 2002 02:30:34 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by 209.249.29.67 with SMTP; 25 Apr 2002 02:30:34 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 568153D37; Wed, 24 Apr 2002 22:30:23 -0400 (EDT) Message-ID: <3CC76A3F.9060502@cygnus.com> Date: Wed, 24 Apr 2002 19:30:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020424 X-Accept-Language: en-us, en MIME-Version: 1.0 To: thorpej@wasabisystems.com Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Use multi-arch'd START_INFERIOR_TRAPS_EXPECTED on Alpha target References: <20020421181544.S1627@dr-evil.shagadelic.org> <3CC74887.2070401@cygnus.com> <20020424180352.B26223@dr-evil.shagadelic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg01002.txt.bz2 > On Wed, Apr 24, 2002 at 08:06:31PM -0400, Andrew Cagney wrote: > > > #define STARTUP_WITH_SHELL 1 > > - #define START_INFERIOR_TRAPS_EXPECTED (STARTUP_WITH_SHELL + 1) > > > Does STARTUP_WITH_SHELL need to be multi-arched? > > > I'm wondering if it would be better to make it a variable (``set > > startup-with-shell ''). Looking at its uses it appears that > > fork-child.c:startup_inferior() would still work (if it did previously). Hmm, ``HP Merge'' ~= ``there be dragons''. > Hm. Actually, it occurs to me that this is more like what we want, but > not quite. What we really want is: > > STARTUP_WITH_SHELL_ADDS_TRAPS > > So, then we get: > > #define START_INFERIOR_TRAPS_EXPECTED \ > (startup_with_shell ? (STARTUP_WITH_SHELL_ADDS_TRAPS + 1) : 1) > > I.e. the issue is really how many extra traps the shell adds. I've included a few more excerts. I think this ``feature'' (only ever worked on HP/UX. Can I suggest taking a step back and making the feature work :-) Andrew PS: I think the relevant bits are: inftarg.c: startup_inferior (START_INFERIOR_TRAPS_EXPECTED); fork-child.c: if (STARTUP_WITH_SHELL) inferior_ignoring_startup_exec_events = ntraps; else inferior_ignoring_startup_exec_events = 0; inferior_ignoring_leading_exec_events = target_reported_exec_events_per_exec_call () - 1; while pre-merge it read (unchanged since '94): /* Accept NTRAPS traps from the inferior. */ void startup_inferior (ntraps) int ntraps; { int pending_execs = ntraps; int terminal_initted; /* The process was started by the fork that created it, but it will have stopped one instruction after execing the shell. Here we must get it up to actual execution of the real program. */ clear_proceed_status (); init_wait_for_inferior (); terminal_initted = 0; #ifdef STARTUP_INFERIOR STARTUP_INFERIOR (pending_execs); #else while (1) { stop_soon_quietly = 1; /* Make wait_for_inferior be quiet */ wait_for_inferior (); if (stop_signal != TARGET_SIGNAL_TRAP) { /* Let shell child handle its own signals in its own way */ /* FIXME, what if child has exit()ed? Must exit loop somehow */ resume (0, stop_signal); } else { /* We handle SIGTRAP, however; it means child did an exec. */ if (!terminal_initted) { /* Now that the child has exec'd we know it has already set its process group. On POSIX systems, tcsetpgrp will fail with EPERM if we try it before the child's setpgid. */ /* Set up the "saved terminal modes" of the inferior based on what modes we are starting it with. */ target_terminal_init (); /* Install inferior's terminal modes. */ target_terminal_inferior (); terminal_initted = 1; } if (0 == --pending_execs) break; resume (0, TARGET_SIGNAL_0); /* Just make it go on */ } } #endif /* STARTUP_INFERIOR */ stop_soon_quietly = 0; }