From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4116 invoked by alias); 21 Dec 2010 12:39:57 -0000 Received: (qmail 4107 invoked by uid 22791); 21 Dec 2010 12:39:57 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 21 Dec 2010 12:39:52 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id oBLCdWru009560; Tue, 21 Dec 2010 13:39:32 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id oBLCdUej013559; Tue, 21 Dec 2010 13:39:30 +0100 (CET) Date: Tue, 21 Dec 2010 12:39:00 -0000 Message-Id: <201012211239.oBLCdUej013559@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: gdb-patches@sourceware.org In-reply-to: <20101221111951.GE2596@adacore.com> (message from Joel Brobecker on Tue, 21 Dec 2010 15:19:51 +0400) Subject: Re: [RFC] how to call host-side stuff from -tdep code? References: <20101221111951.GE2596@adacore.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-12/txt/msg00372.txt.bz2 > Date: Tue, 21 Dec 2010 15:19:51 +0400 > From: Joel Brobecker > > Hello, > > I am about 75% through porting FSF HEAD to ia64-hpux, and I have > a question: > > I'm inside ia64-tdep.c, and I need to determine whether we're inside > a system call or not. Apparently, the way to do that is to perform > a call to ttrace (I'm planning on wrapping this inside a -nat.c file). > But of course, you are not supposed to do that, since the -nat module > is not available in the case of a cross debugger. > > To be more precise, the ttrace request is a TT_LWP_RUREGS, using > an offset set to __reason. If the returned value is zero, then > we're in a syscall. Otherwise, we're not. In a way, this could > be thought of as a special register. There is a precedent for doing it this way; i386/amd64 Linux has $orig_eax/$orif_rax, which have some magical meaning for syscalls. > I don't think that adding a raw register would be really be all > that appealing, since it'd be accessible to the user. That isn't necessarily a bad thing. It offers the user an opportunity to write scripts that check it as well. And you can always hide the raw register by giving it an empty string as its name. But if it isn't somehow related to the contents of a architectural-defined register, I wouldn't go this way. > I thought about a pseudo register, but this seems awkward, if possible > at all. My understanding is that pseudo-registers are really a thing > of the target, which cannot depend on native stuff. The purpose of psuedo registers is basically to provide a different view of the raw registers to the user. > It seems to me that the easiest solution right now is to add a new > xfer object (say TARGET_OBJECT_IA64/"ia64.in_syscall"), and then > use target_xfer_partial to get the information I needed. Is that > what these objects were meant for? I'd say so. On OpenBSD/sparc and OpenBSD/sparc64 I introduced TARGET_OBJECT_WCOOKIE to get at the magic cookie to "decrypt" the mangled registers that are saved on the stack by StackGhost. I'd say this is the way to go, but it sounds like this is rather HP-UX specific rather than a general feature on ia64, so perhaps you should choose a different name.