[RFC] how to call host-side stuff from -tdep code?

[RFC] how to call host-side stuff from -tdep code?

[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.

I don't think that adding a raw register would be really be all
that appealing, since it'd be accessible to the user.

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.

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 considered adding a new target method, but that seems way overkill,
just for one platform.

Any other suggestion?

-- 
Joel

Re: [RFC] how to call host-side stuff from -tdep code?

[Mark Kettenis]

> Date: Tue, 21 Dec 2010 15:19:51 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> 
> 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.