linux-um archives
 help / color / mirror / Atom feed
From: Blaisorblade <blaisorblade_spam@yahoo.it>
To: user-mode-linux-devel@lists.sourceforge.net
Cc: Bodo Stroesser <bstroesser@fujitsu-siemens.com>,
	Jeff Dike <jdike@addtoit.com>
Subject: Re: [uml-devel] Patchset to implement PTRACE_SYSEMU_SINGLESTEP
Date: Sat, 13 Nov 2004 00:43:25 +0100	[thread overview]
Message-ID: <200411130043.25888.blaisorblade_spam@yahoo.it> (raw)
In-Reply-To: <419517A4.7020700@fujitsu-siemens.com>

On Friday 12 November 2004 21:05, Bodo Stroesser wrote:
> Attached are several patches. Four of them (patch-2.6.*-skas-v7-*)
> implement PTRACE_SYSEMU_SINGLESTEP in the host. They are based on
> linux-2.6.7-vanilla + host-skas3-2.6.7-v7.patch (resp. the 2.6.9 versions).
> The "-reorganize" patches are a rework of the current patch without
> changing the functionality. The "add-SYSEMU_SINGLESTEP" then implement the
> new features. Please note: the differences between 2.6.7 and 2.6.9 are
> dependent on the different handling of syscall singlestepping in the two
> versions.
>
> To have UML using the new feature, there are two further patches named
> patch-SYSEMU_SINGLESTEP-*. They are based on linux-2.6.9-vanilla +
> all bb2-patches + patch-sysemu-tt + patch-fix-uml-hang-on-2.6.9-host.
> To have all the patches complete, the latter two are attached also.
>
> I tested on host 2.6.7 and host 2.6.9 with SKAS and TT mode. Currently I
> don't know any problem with it.

> Bodo

> BTW: Today I tried the first time since weeks to do a reboot in SKAS. It
> simply exits UML, as it did weeks ago. Is there anybody involved with that
> problem?

It seems a bit randomical: on my system, it segfaults some times, after 
checking for /proc/mm and SKAS mode.

When applying my use-va_end patch, (it's also in Jeff incrementals), instead, 
it always gets this segfault.

If you look at the comment about exec(), it says that UML risks to get some 
signals after the exec(). It workarounds this for some signals, but this 
cannot be done anyway for SIGSEGV... actually SIGSEGV delivery happens to 
always be synchronous, since the process gets trapped before the signal is 
queued.

By comparison, all signals are normally asynchronous, i.e. they get queued and 
later delivered, so that deliverying a signal is slower than doing a context 
switch.

Quoting from signal(7) man page:

Multiple instances of real-time signals can be queued.  By contrast,  if  
multiple instances of  a standard  signal  are  delivered  while  that signal 
is currently blocked, then only one instance is queued.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

  reply	other threads:[~2004-11-12 23:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-12 20:05 [uml-devel] Patchset to implement PTRACE_SYSEMU_SINGLESTEP Bodo Stroesser
2004-11-12 23:43 ` Blaisorblade [this message]
2004-11-15 17:11   ` Bodo Stroesser
2004-11-18  6:47     ` Jeff Dike
2004-11-18 14:19       ` Bodo Stroesser
2004-11-18 14:41         ` Blaisorblade
2004-11-18 16:01           ` Bodo Stroesser
2004-12-06 20:33 ` Blaisorblade
2004-12-07 14:21   ` Bodo Stroesser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200411130043.25888.blaisorblade_spam@yahoo.it \
    --to=blaisorblade_spam@yahoo.it \
    --cc=bstroesser@fujitsu-siemens.com \
    --cc=jdike@addtoit.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox