Re: [PATCH hurd] Update rpctrace to use the new ABI for inlined port names

Applied, thanks! Flavio Cruz, le dim. 21 janv. 2024 23:35:40 -0500, a ecrit: > --- > utils/rpctrace.c | 83 +++- > 1 file changed, 53 insertions(+), 30 deletions(-) > > diff --git a/utils/rpctrace.c b/utils/rpctrace.c > index f7046a0..c8635a3 100644 >

[PATCH hurd] Update rpctrace to use the new ABI for inlined port names

--- utils/rpctrace.c | 83 +++- 1 file changed, 53 insertions(+), 30 deletions(-) diff --git a/utils/rpctrace.c b/utils/rpctrace.c index f7046a0..c8635a3 100644 --- a/utils/rpctrace.c +++ b/utils/rpctrace.c @@ -801,6 +801,18 @@ rewrite_right (mach_port_

Re: [PATCH hurd] Improve portability for rpctrace on x86_64

#include "msgids.h" > > +/* Should match MiG's desired_complex_alignof */ > +#define MSG_ALIGNMENT __alignof__(uintptr_t) > + > const char *argp_program_version = STANDARD_HURD_VERSION (rpctrace); > > static unsigned strsize = 80; > @@ -807,7 +810,7 @@ print_c

[PATCH hurd] Improve portability for rpctrace on x86_64

argp_program_version = STANDARD_HURD_VERSION (rpctrace); static unsigned strsize = 80; @@ -807,7 +810,7 @@ print_contents (mach_msg_header_t *inp, int first = 1; /* Process the message data, wrapping ports and printing data. */ - while (msg_buf_ptr < (void *) inp + inp->msgh_size) + while (

Re: [PATCH htl v3 5/5] testrun.sh: Add support for --tool=rpctrace

Applied this patch, thanks! Samuel Florian Weimer, le mer. 08 sept. 2021 08:57:43 +0200, a ecrit: > * Sergey Bugaev: > > > rpctrace(1) is a Hurd RPC tracer tool, which is used similar to how > > strace(1) is used on GNU/Linux. > > > > Signed-off-by: Sergey Bug

Re: [PATCH htl v3 5/5] testrun.sh: Add support for --tool=rpctrace

* Sergey Bugaev: > rpctrace(1) is a Hurd RPC tracer tool, which is used similar to how > strace(1) is used on GNU/Linux. > > Signed-off-by: Sergey Bugaev > --- > Makefile | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/Makefile b/

[PATCH htl v3 5/5] testrun.sh: Add support for --tool=rpctrace

rpctrace(1) is a Hurd RPC tracer tool, which is used similar to how strace(1) is used on GNU/Linux. Signed-off-by: Sergey Bugaev --- Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index f98d5a9e67..a49870d3d1 100644 --- a/Makefile +++ b

[RFC PATCH htl v2 3/4] testrun.sh: Add support for --tool=rpctrace

rpctrace(1) is a Hurd RPC tracer tool, which is used similar to how strace(1) is used on GNU/Linux. Signed-off-by: Sergey Bugaev --- Makefile | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index f98d5a9e67..a49870d3d1 100644 --- a/Makefile +++ b

Re: rpctrace output improvements?

On Sat, May 15, 2021 at 4:56 PM Samuel Thibault wrote: > > * rpctrace has to learn to parse defs, instead of (or in addition to) msgids > > * GNU MIG needs to be taught to emit more info into msgids files > > Either of those. Probably the latter would be more interesting >

Re: rpctrace output improvements?

ndeed and is most often available in the types > > already. > > Oh, do you mean the types specified in .defs? Yes. > * rpctrace has to learn to parse defs, instead of (or in addition to) msgids > * GNU MIG needs to be taught to emit more info into msgids files Either of those. P

Re: rpctrace output improvements?

specified in .defs? If so, the problem is rpctrace doesn't read those, it only reads the msgids files, which contain lines like this: fs 2 dir_lookup 18 20018 20118 (meaning, subsystem fs whose base msgid is 2, routine name is dir_lookup, msgid relative to subsystem base is 18, absolute

Re: rpctrace output improvements? OFF TOPIC PRAISE

May 12, 2021 5:15 PM, "Samuel Thibault" wrote: > Sergey Bugaev, le jeu. 13 mai 2021 00:12:14 +0300, a ecrit: > >> On Wed, May 12, 2021 at 11:48 PM Samuel Thibault >> wrote: >>> * Symbolicated flags and file paths (potentially, also proc and auth >>> handles) >> > >> P. S. Could you please ta

Re: rpctrace output improvements?

Sergey Bugaev, le jeu. 13 mai 2021 00:12:14 +0300, a ecrit: > On Wed, May 12, 2021 at 11:48 PM Samuel Thibault > wrote: > > > * Symbolicated flags and file paths (potentially, also proc and auth > > > handles) > > > > For file path it'll probably be much harder since there can be several > > path

Re: rpctrace output improvements?

icalize_directory_name_internal () with directories (previously unknown ports when they're used as a request port in a dir_* RPC), and take note of file paths as file ports are received from dir_lookup (). This should catch all files that the tracee opens; but not any fds it inherits. This should not be

Re: rpctrace output improvements?

Hello, Sergey Bugaev, le mer. 12 mai 2021 20:37:55 +0300, a ecrit: > 111<--144(pid1004)->dir_lookup ("proc/loadavg" 1 0) = 0 1 "loadavg" > 163<--162(pid1004) > task133(pid1004)->mach_port_mod_refs (pn{ 21} 0 1) = 0 > 163<--162(pid1004)->dir_lookup ("loadavg" 1 0) = 0 1 "" > 165<--158(pi

rpctrace output improvements?

Hello, I use rpctrace a lot, but I'm not particularly fond of its output format. Other tracing tools, like strace [0] on Linux and Darling's xtrace [1] can symbolicate many flags and structures, producing something that looks much closer to C code, and comprehensible at a glance.

[bug #56407] rpctrace fails on statically linked binaries

URL: <https://savannah.gnu.org/bugs/?56407> Summary: rpctrace fails on statically linked binaries Project: The GNU Hurd Submitted by: baccala Submitted on: Tue 28 May 2019 04:29:50 PM UTC Category

rpctrace on a statically linked executable

xecutable that works fine, but can't be traced: root@qemu-hurd:~# rpctrace ./hello-world task134(pid8538)->vm_statistics () = 0 {4096 462739 56607 206740 23868 12642497 0 424184 481063 142824515 37245163 15804468 15747574} Child 8538 Killed A little more digging shows that the progr

attaching rpctrace to running processes

Hi - I've modified rpctrace to attach to running processes and trace them. I've added a new set of patches (the 0200 series) to my github repository with these changes. I'm still chasing bugs, and it can't detach from processes without killing them, but it's basical

libpager, proc server, rpctrace, and other meandering

urd and the subhurd, but I can't quite puzzle it out. So, I thought to myself, why not modify rpctrace so that it can attach to the proc server and trace it? Maybe I could modify startup to start proc with rpctrace wrapped around it, but we eventually want rpctrace to attach and detach runnin

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

On Tue, 2017-12-19 at 10:39 +0100, Samuel Thibault wrote: > Svante Signell, on mar. 19 déc. 2017 10:36:22 +0100, wrote: > > And FYI: gdb is totally unusable, the only output is threads are created an > > then > > a hard hang of gdb, only resolvable with kill -9 from another terminal. I > > tried >

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

Svante Signell, on mar. 19 déc. 2017 10:36:22 +0100, wrote: > And FYI: gdb is totally unusable, the only output is threads are created an > then > a hard hang of gdb, only resolvable with kill -9 from another terminal. I > tried > to start another gdb on /hurd/ext2fs an attaching to the hanged pr

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

On Sun, 2017-11-19 at 20:04 -0500, Brent W. Baccala wrote: > On Fri, Nov 17, 2017 at 3:14 PM, Svante Signell > wrote: > > Thanks a lot for your patches for rpctrace. Now more failing programs > > can be traced, where the standard version fails. There are still some > >

Re: FSF copyright assignment (was: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs)

On Mon, Nov 20, 2017 at 3:33 AM, Samuel Thibault wrote: > Brent W. Baccala, on dim. 19 nov. 2017 20:04:35 -0500, wrote: > > The assignment of par. 1(a) above applies to all > > past and future works of Developer that > constitute > > changes

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

Brent W. Baccala, on dim. 19 nov. 2017 20:04:35 -0500, wrote: > The   assignment   of   par.   1(a)   above   applies   to   all  >  past   and   future   works   of   Developer   that   constitute  >  changes   and > enhancements to the Program. > > An obvious read

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

On Fri, Nov 17, 2017 at 3:14 PM, Svante Signell wrote: > > Thanks a lot for your patches for rpctrace. Now more failing programs > can be traced, where the standard version fails. There are still some > examples hanging hard on gsync_wait or entering an infinite loop. > >

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

tigated further. > > > > Thanks, I will try to apply them: Do I need all 0001 to 0011 and > > 0101 to 0102 > > patches? > > > > I'm not sure exactly which ones you absolutely need.  The 0100 series > is documentation, so you definitely don't need

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

On Thu, Nov 16, 2017 at 5:55 PM, Svante Signell wrote: > > > Perhaps you could try those patches and see if they fix your problem? > If not, > > then it's something else that should be investigated further. > > Thanks, I will try to apply them: Do I need all 0001 to 0011 and 0101 to > 0102 > patc

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

On Thu, 2017-11-16 at 12:25 -0500, Brent W. Baccala wrote: > On Wed, Nov 15, 2017 at 11:53 AM, Svante Signell > wrote: > > Has rpctrace been thoroughly tested on multi-thread applications? > > Please, give feedback on this if you have possibility, specifically the

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

On Thu, Nov 16, 2017 at 12:39 PM, Samuel Thibault wrote: > Hello, > > Brent W. Baccala, on jeu. 16 nov. 2017 12:25:23 -0500, wrote: > > This isn't in the main Hurd repository because I wouldn't sign the FSF > > copyright assignment. They insisted on a clause that said I assign > copyright > > on

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

Hello, Brent W. Baccala, on jeu. 16 nov. 2017 12:25:23 -0500, wrote: > This isn't in the main Hurd repository because I wouldn't sign the FSF > copyright assignment.  They insisted on a clause that said I assign copyright > on "all past and future works of Developer that constitute changes and > e

Re: SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

On Wed, Nov 15, 2017 at 11:53 AM, Svante Signell wrote: > > Additionally the rpctrace output hangs hard at gsync_wait() both for the > ./index0-out-reduced_OK.x and ./index0-out-reduced_nOK.x files. > Has rpctrace been thoroughly tested on multi-thread applications? > > Please

SIGILL problems with Hurd port of GO in gcc-8, and rpctrace bugs.

to be a memory issue/*context problem. pthread_create does not seem to be the cuplrit, but who knows.  Additionally the rpctrace output hangs hard at gsync_wait() both for the ./index0-out-reduced_OK.x and ./index0-out-reduced_nOK.x files. Has rpctrace been thoroughly tested on multi-thread applica

Re: rpctrace / libpager / signal preemptor

On Wed, Nov 30, 2016 at 11:12 PM, Samuel Thibault wrote: > > Err, I'm sorry, did you perhaps miss the fix I made after: > > commit 406b031c996ec4cd8c76d251de8b7bf462d8b975 > Author: Samuel Thibault > Date: Sun Nov 20 16:16:24 2016 +0100 > > Fix SIGBUS code > Err, yes, I missed that. I do

Re: rpctrace / libpager / signal preemptor

Hello, Brent W. Baccala, on Wed 30 Nov 2016 22:47:09 -1000, wrote: > The patch works, but is incomplete.  Samuel's test programs attempt to access > unmapped memory addresses, which generate KERN_MEMORY_FAILURE, but ext2fs > attempts to access mapped addresses back by a memory manager returning fa

Re: rpctrace / libpager / signal preemptor

On Wed, Nov 16, 2016 at 9:05 AM, Samuel Thibault wrote: > Samuel Thibault, on Wed 16 Nov 2016 19:50:07 +0100, wrote: > > Samuel Thibault, on Wed 16 Nov 2016 19:46:52 +0100, wrote: > > > The attached testcase does get the faulting address. > > > > And the attached testcase doesn't. > > And is fixe

Re: rpctrace / libpager / signal preemptor

Samuel Thibault, on Mon 21 Nov 2016 09:16:19 +0100, wrote: > Brent W. Baccala, on Sun 20 Nov 2016 21:50:04 -1000, wrote: > > I suppose I could test your patch just by building the > > library itself, but the Debian package build calls "make check" and it's > > causing me all kinds of grief. > > Y

Re: rpctrace / libpager / signal preemptor

Hello, Brent W. Baccala, on Sun 20 Nov 2016 21:50:04 -1000, wrote: > I suppose I could test your patch just by building the > library itself, but the Debian package build calls "make check" and it's > causing me all kinds of grief. You can use export DEB_BUILD_OPTIONS=nocheck to avoid that, se

Re: rpctrace / libpager / signal preemptor

On Sun, 2016-11-20 at 21:50 -1000, Brent W. Baccala wrote: > On Sun, Nov 20, 2016 at 5:37 AM, Samuel Thibault > wrote: > > Samuel Thibault, on Sun 20 Nov 2016 14:50:50 +0100, wrote: > >  > Sorry I haven't answered for a few days.  I've been trying to test your patch > by building a new glibc packa

Re: rpctrace / libpager / signal preemptor

On Sun, Nov 20, 2016 at 5:37 AM, Samuel Thibault wrote: > Samuel Thibault, on Sun 20 Nov 2016 14:50:50 +0100, wrote: > > Samuel Thibault, on Wed 16 Nov 2016 20:05:49 +0100, wrote: > > > Samuel Thibault, on Wed 16 Nov 2016 19:50:07 +0100, wrote: > > > > And is fixed by the attached patch, could yo

Re: rpctrace / libpager / signal preemptor

Samuel Thibault, on Sun 20 Nov 2016 14:50:50 +0100, wrote: > Samuel Thibault, on Wed 16 Nov 2016 20:05:49 +0100, wrote: > > Samuel Thibault, on Wed 16 Nov 2016 19:50:07 +0100, wrote: > > > Samuel Thibault, on Wed 16 Nov 2016 19:46:52 +0100, wrote: > > > > The attached testcase does get the faulting

Re: rpctrace / libpager / signal preemptor

Samuel Thibault, on Wed 16 Nov 2016 20:05:49 +0100, wrote: > Samuel Thibault, on Wed 16 Nov 2016 19:50:07 +0100, wrote: > > Samuel Thibault, on Wed 16 Nov 2016 19:46:52 +0100, wrote: > > > The attached testcase does get the faulting address. > > > > And the attached testcase doesn't. > > And is f

Re: rpctrace / libpager / signal preemptor

Samuel Thibault, on Wed 16 Nov 2016 19:50:07 +0100, wrote: > Samuel Thibault, on Wed 16 Nov 2016 19:46:52 +0100, wrote: > > The attached testcase does get the faulting address. > > And the attached testcase doesn't. And is fixed by the attached patch, could you try it? Samuel Index: glibc-2.24/s

Re: rpctrace / libpager / signal preemptor

Samuel Thibault, on Wed 16 Nov 2016 19:46:52 +0100, wrote: > The attached testcase does get the faulting address. And the attached testcase doesn't. > I really believe the issue is related to this: Confirmed :) > > Note that there is a > > > > /* XXX what if handler != action->handler (for

Re: rpctrace / libpager / signal preemptor

Samuel Thibault, on Mon 14 Nov 2016 01:07:40 +0100, wrote: > > Once that's been resolved, then we're back to the problem with signal > > preemptors!  libpager/pager-memcpy.c includes the following code: > > > >   void fault (int signo, long int sigcode, struct sigcontext *scp) > >     { > >  

Re: rpctrace / libpager / signal preemptor

Hello, Brent W. Baccala, on Tue 08 Nov 2016 20:43:29 -1000, wrote: >    _pager_lock_object (p, offset, length, MEMORY_OBJECT_RETURN_NONE, 1, > - VM_PROT_WRITE, 1); > +   VM_PROT_WRITE, 0); Applied, thanks! > Once that's been resolved, then we're back to th

rpctrace / libpager / signal preemptor

processing a data_unlock request, and would have to handle a lock_completed message before lock_object would return (synchronously). Next, there's a problem with the rpctrace code that I recently modified, specifically the part that synchronizes messages by processing them in order of their &#x

Re: [PATCH 1/8] remove warning messages on rpctrace from 'asprintf'

"Brent W. Baccala" writes: > + va_start(argptr, fmt); > + retval = vasprintf(strp, fmt, argptr); > + va_end(argptr); > + > + assert_perror(retval == -1); The argument of assert_perror should be an errno_t value, not just a Boolean. It isn't clear from the commit message that the warning mes

Re: rpctrace man page

Hello! Thanks for taking care of the manual! Just a very very partial review… "Brent W. Baccala" skribis: > +@node rpctrace > +@section rpctrace The convention would be to call this section “Invoking rpctrace”, so: @node Invoking rpctrace @section Invoking @

Re: two more rpctrace patches

gt;> which generates a ChangeLog file from those. >> > > OK, I think I see what you want. > Was that last patch in the desired format? Would you like me to reformat the commit messages on the last ten rpctrace patches and resubmit them? agape brent

[PATCH] rpctrace: Don't allocate an unneeded structure

* utils/rpctrace.c (trace_and_forward): Don't allocate request structure 'req' unless we actually expect a reply --- utils/rpctrace.c | 28 +--- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/utils/rpctrace.c b/utils/rpctrace.c index 2664ffd..6086ab6 100644

Re: two more rpctrace patches

On Wed, Nov 2, 2016 at 2:26 PM, Kalle Olavi Niemitalo wrote: > > Look at how the commit messages in hurd.git at Savannah (not at > Debian) are formatted. "make dist" runs gitlog-to-changelog, > which generates a ChangeLog file from those. > OK, I think I see what you want.

Re: two more rpctrace patches

"Brent W. Baccala" writes: > How do you submit changelog-style descriptions? They don't seem to be kept > in ChangeLog... Look at how the commit messages in hurd.git at Savannah (not at Debian) are formatted. "make dist" runs gitlog-to-changelog, which generates a ChangeLog file from those. (

Re: two more rpctrace patches

On Wed, Nov 2, 2016 at 3:10 AM, Justus Winter wrote: > > Cool. Two nitpicks: 1/ Instead of attaching patches, why don't you use > git send-email. That is easier for everyone. 2/ The summary line of > your patches is too long, try to keep it at ~60 chars or so, and we > require changelog-style

Re: two more rpctrace patches

Hi! "Brent W. Baccala" writes: > I'm attaching two more patches to rpctrace that close bug 48863. Cool. Two nitpicks: 1/ Instead of attaching patches, why don't you use git send-email. That is easier for everyone. 2/ The summary line of your patches is too long, try

Re: rpctrace man page

On Tue, Nov 1, 2016 at 5:15 AM, Samuel Thibault wrote: > > GNU projects usually don't have man pages, but info pages. The > doc/hurd.texi indeed doesn't have any part for rpctrace. It should :) > > What an embarrassing *faux pas*! It's like fumbling to put t

two more rpctrace patches

Aloha - I'm attaching two more patches to rpctrace that close bug 48863. agape brent From 10a2a49e370ca55b6cea4cdc4a54ae106b243817 Mon Sep 17 00:00:00 2001 From: Brent Baccala Date: Tue, 1 Nov 2016 01:07:52 -1000 Subject: [PATCH 1/2] rpctrace: don't wrap send-once rights s

Re: rpctrace man page

Hello, Brent W. Baccala, on Mon 31 Oct 2016 21:00:53 -1000, wrote: > How about writing a man page? GNU projects usually don't have man pages, but info pages. The doc/hurd.texi indeed doesn't have any part for rpctrace. It should :) I also notice that "info settrans" d

rpctrace man page

Hmm... maybe somebody on the list will fix the gsync bug, since I don't know how... ...what can I do in the meantime... How about writing a man page? agape brent rpctrace.1 Description: Binary data

Re: [PATCH 8/8] rpctrace: use condition variable to keep messages in sequence

't see any way around it now. If you can suggest something, let me > know... If rpctrace could detect whether the memory_object_data_request RPC was caused by one of its threads, it could set the condition variable on behalf of that thread then. However, this won't work if rpctrace d

Re: [PATCH 8/8] rpctrace: use condition variable to keep messages in sequence

you want me to prepare a > combined patch and email it in? > OK, I'm attaching the combined patch7+patch8. I've studied it a bit more, and it has a race condition that looks unavoidable to me. rpctrace on ext2fs exposes the problem. ext2fs maps a region of memory that it ma

Re: [PATCH 1/8] remove warning messages on rpctrace from 'asprintf'

0:00:00 2001 From: Brent Baccala Date: Thu, 20 Oct 2016 20:46:32 -1000 Subject: [PATCH] remove warning messages on rpctrace from 'asprintf' --- utils/rpctrace.c | 50 -- 1 file changed, 32 insertions(+), 18 deletions(-) diff --git a/utils

Re: [PATCH 1/8] remove warning messages on rpctrace from 'asprintf'

Hello, Brent W. Baccala, on Sat 29 Oct 2016 13:40:24 -1000, wrote: > > Also, I don't see copyright assignment in the FSF records, did you start > > making one? > > No, I haven't.  What should I use, request-assign.program, sent to > fsf-records? request-assign.future, rather, sent to ass...@gnu

Re: [PATCH 8/8] rpctrace: use condition variable to keep messages in sequence

Brent W. Baccala, on Sat 29 Oct 2016 13:48:23 -1000, wrote: > I had thought of the entire patch set being applied monolithically. Yes, but that'll still appear as separate commits, that some people might fall in the middle of while bisecting something. > Yes, patch7 without patch8 can reorder mes

Re: [PATCH 8/8] rpctrace: use condition variable to keep messages in sequence

On Oct 29, 2016 2:55 AM, "Samuel Thibault" wrote: > > Hello, > > Better apply this patch before patch7, shouldn't we? Otherwise there's > a little git interval during which rpctrace is unreliable. > > Samuel I had thought of the entire patch set b

Re: [PATCH 1/8] remove warning messages on rpctrace from 'asprintf'

On Oct 29, 2016 2:53 AM, "Samuel Thibault" wrote: > > Hello, > > > #define easprintf(args...)assert(asprintf (args) != -1) > > That will be removed when building with -DNDEBUG, not a good thing :) An excellent point. I'll revise PATCH 1 tomorrow. > Also, I don't see copyright assignment

Re: [PATCH 8/8] rpctrace: use condition variable to keep messages in sequence

Hello, Better apply this patch before patch7, shouldn't we? Otherwise there's a little git interval during which rpctrace is unreliable. Samuel

Re: [PATCH 1/8] remove warning messages on rpctrace from 'asprintf'

Hello, > #define easprintf(args...)assert(asprintf (args) != -1) That will be removed when building with -DNDEBUG, not a good thing :) Also, I don't see copyright assignment in the FSF records, did you start making one? Samuel

[PATCH 6/8] rpctrace: handle unknown send rights from tasks that don't hold the matching receive right, and eliminate dummy_wrapper

--- utils/rpctrace.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/utils/rpctrace.c b/utils/rpctrace.c index c587736..015f765 100644 --- a/utils/rpctrace.c +++ b/utils/rpctrace.c @@ -230,7 +230,7 @@ remove_request (mach_msg_id_t req_id, mach_port_t

[PATCH 3/8] rpctrace: rewrite_right() now takes source and dest task_t arguments, instead of taking an entire RPC request structure, which sometimes needs to be fabricated in order to use rewrite_righ

also, drop special handling of mach_port_extract_right RPC --- utils/rpctrace.c | 38 ++ 1 file changed, 10 insertions(+), 28 deletions(-) diff --git a/utils/rpctrace.c b/utils/rpctrace.c index e33265f..caa77b0 100644 --- a/utils/rpctrace.c +++ b/utils/rpctrace

[PATCH 4/8] rpctrace: determine destination task for send-once rights

--- utils/rpctrace.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/utils/rpctrace.c b/utils/rpctrace.c index caa77b0..6922c70 100644 --- a/utils/rpctrace.c +++ b/utils/rpctrace.c @@ -1102,6 +1102,8 @@ trace_and_forward (mach_msg_header_t *inp, mach_msg_heade

[PATCH 8/8] rpctrace: use condition variable to keep messages in sequence

--- utils/rpctrace.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/utils/rpctrace.c b/utils/rpctrace.c index 88b5e38..09911b3 100644 --- a/utils/rpctrace.c +++ b/utils/rpctrace.c @@ -131,6 +131,8 @@ struct traced_info mach_msg_type_name_t type; char

[PATCH 5/8] rpctrace: don't search unknown_task for receive rights

--- utils/rpctrace.c | 1 + 1 file changed, 1 insertion(+) diff --git a/utils/rpctrace.c b/utils/rpctrace.c index 6922c70..c587736 100644 --- a/utils/rpctrace.c +++ b/utils/rpctrace.c @@ -498,6 +498,7 @@ discover_receive_right (mach_port_t send, task_t task) && info->portname == UNKNOWN

[PATCH 7/8] multithread rpctrace to avoid deadlocks in the kernel

hread_mutex_unlock(&tracelock); return 1; } /* Get some unexpected notification for rpctrace itself, @@ -1180,6 +1195,7 @@ trace_and_forward (mach_msg_header_t *inp, mach_msg_header_t *outp) { ports_port_deref (info); ((mig_reply_

[PATCH 1/8] remove warning messages on rpctrace from 'asprintf'

--- utils/rpctrace.c | 40 ++-- 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/utils/rpctrace.c b/utils/rpctrace.c index 25d9bc6..8aef88d 100644 --- a/utils/rpctrace.c +++ b/utils/rpctrace.c @@ -59,6 +59,9 @@ static const struct argp_option opti

rpctrace

Hi - I've made some decent progress with rpctrace this week. I think I pretty much understand this program now! In particular, I've gotten it working on ext2fs. I had to fix the problem I described earlier with send-once rights, and then deal with a deadlock situation caused when ext

Re: rpctrace design

On Mon, Oct 24, 2016 at 1:12 AM, Justus Winter wrote: > > "Brent W. Baccala" writes: > > I read on the website's hurd/debugging/rpctrace page that somebody > (zhenga) > > had come with a new version of rpctrace. Do we have a copy of it around > >

Re: rpctrace design

Hey, I don't have time to look into that in detail now, but "Brent W. Baccala" writes: > I read on the website's hurd/debugging/rpctrace page that somebody (zhenga) > had come with a new version of rpctrace. Do we have a copy of it around > somewhere? We m

rpctrace design

Aloha - I've been trying to debug a problem in rpctrace which causes rpctrace to crash when I use it to wrap /hurd/ext2fs. The bug is triggered by a memory_object_lock_request / memory_object_lock_completed sequence. Specifically, ext2fs sends a lock request to the kernel with a send

[bug #26476] rpctrace cannot trace messages sent to the host port

name port to the child task, I think rpctrace will make a separate wrapper. The principle in rpctrace seems to be that each task should have its own send wrappers, so that rpctrace can show which task sent messages to the port. To fix this properly, I think wrap_new_task would have to be changed

[bug #26476] rpctrace cannot trace messages sent to the host port

Follow-up Comment #3, bug #26476 (project hurd): I tried implementing (a). Surprisingly, "rpctrace ls" does not show any messages to the host name port, when using libc0.3 2.23-4 from Debian. Running the patched rpctrace on the test program (file #36320) shows the host_processor_set

[bug #26476] rpctrace cannot trace messages sent to the host port

Follow-up Comment #2, bug #26476 (project hurd): a) makes sense to me indeed. Implementing an strace tool could however be useful too, though :) ___ Reply to this item at:

[bug #26476] rpctrace cannot trace messages sent to the host port

ernel apparently has that. The GNU Mach change would probably be simple, the GNU C Library wouldn't have to be changed, and in the Hurd only rpctrace would have to be changed. (b) Delete mach_task_port, and instead define INIT_PORT_HOST in so that the new task can query it from exec_startu

Re: [PATCH] rpctrace: Print beyond '\0' in MACH_MSG_TYPE_CHAR.

Kalle Olavi Niemitalo, on Wed 24 Aug 2016 00:41:30 +0300, wrote: > This will now display the 'argv: data_t' argument of file_exec > as e.g. "who\0am\0i\0" rather than just "who". Applied, thanks! Samuel

[PATCH] rpctrace: Print beyond '\0' in MACH_MSG_TYPE_CHAR.

This will now display the 'argv: data_t' argument of file_exec as e.g. "who\0am\0i\0" rather than just "who". In contrast, the 'file_name: string_t' argument of dir_lookup will still be truncated at the first null character. The previous implementation might crash if an out-of-line char array exa

[bug #48863] rpctrace crashes (failed assert) when SEND ONCE right is extracted and then sent

URL: <http://savannah.gnu.org/bugs/?48863> Summary: rpctrace crashes (failed assert) when SEND ONCE right is extracted and then sent Project: The GNU Hurd Submitted by: baccala Submitted on: Tue 23 Aug 2016 08:21:13

[bug #26476] rpctrace cannot trace messages sent to the host port

Update of bug #26476 (project hurd): Status:None => Confirmed Summary: rpctrace cannot handle host_processor_sets() => rpctrace cannot trace messages sent to the hos

Re: [PATCH hurd 2/2] utils/rpctrace: fix notification port handling

Justus Winter, le Tue 20 Jan 2015 20:30:59 +0100, a écrit : > * utils/rpctrace.c (new_receiver_info): Fix handling of old > notification port. Ack, thanks! > --- > utils/rpctrace.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/utils/rpctrace.c b/utils/rpctrace.c > i

[PATCH hurd 2/2] utils/rpctrace: fix notification port handling

* utils/rpctrace.c (new_receiver_info): Fix handling of old notification port. --- utils/rpctrace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/utils/rpctrace.c b/utils/rpctrace.c index 62d3c87..48daa07 100644 --- a/utils/rpctrace.c +++ b/utils/rpctrace.c @@ -404,7 +404,8

Re: [PATCH hurd 26/30] utils/rpctrace: make `trace_and_forward' payload-aware

Justus Winter, le Thu 27 Nov 2014 14:19:06 +0100, a écrit : > As the protected payloads were retrofitted into the Mach message > format, the local port type is lost. > > * utils/rpctrace.c (is_notification): New function > (trace_and_forward): Recover the original local port type. Ack. > --- >

[PATCH hurd 26/30] utils/rpctrace: make `trace_and_forward' payload-aware

As the protected payloads were retrofitted into the Mach message format, the local port type is lost. * utils/rpctrace.c (is_notification): New function (trace_and_forward): Recover the original local port type. --- utils/rpctrace.c | 29 - 1 file changed, 28 insertion

Re: [PATCH hurd] utils/rpctrace: fix crash while printing messages

Justus Winter, le Wed 12 Nov 2014 13:31:04 +0100, a écrit : > % fakeroot rpctrace install > [...] > 63<--66(pid5363)->io_read (-1 8192) = 0 [... rpctrace crashes] > /bin/fakeauth: Segmentation fault for child 5362 > /bin/settrans: Error 139 for child 5361 > > * u

[PATCH hurd] utils/rpctrace: fix crash while printing messages

% fakeroot rpctrace install [...] 63<--66(pid5363)->io_read (-1 8192) = 0 [... rpctrace crashes] /bin/fakeauth: Segmentation fault for child 5362 /bin/settrans: Error 139 for child 5361 * utils/rpctrace.c (print_data): Fix this by guarding the code escaping non-printable characters intr

[PATCH hurd 8/8] utils/rpctrace: support attaching to servers

,8 @@ ps w ids settrans syncfs showtrans fsysopts storeinfo login vmstat portinfo \ $(filter-out $(special-targets), $(targets)): %: %.o -rpctrace: ../libports/libports.a ../libihash/libihash.a +rpctrace: ../libports/libports.a ../libihash/libihash.a \ + ../libintrospection/libintrospecti

Re: [PATCH 4/4] utils/rpctrace: escape non-printable characters in strings

Justus Winter, le Fri 13 Dec 2013 13:03:07 +0100, a écrit : > * utils/rpctrace.c (escape_sequences): New char array mapping > characters to their escape sequence. > (print_data): Escape non-printable characters when printing strings. Ack on the principle for a fixed patch :) > --- > utils/rpctra

Re: [PATCH 4/4] utils/rpctrace: escape non-printable characters in strings

Justus Winter, le Sat 14 Dec 2013 13:42:17 +0100, a écrit : > Quoting Ivan Shmakov (2013-12-13 17:05:19) > > PS. Doesn’t Gnulib provide such a function already? > > Is it ok to use gnulib stuff in the Hurd? In rpctrace it would probably not be a problem. About the code impor

Re: [PATCH 5/5] utils/rpctrace: fix output so that replies can be attributed to requests

Justus Winter, le Fri 13 Dec 2013 15:52:38 +0100, a écrit : > Currently, it is impossible to properly attribute response messages to > requests. Even though rpctrace is single-threaded, its tracee may > not. Or there might be more than one tracee. In any such case it is > not gua

Re: [PATCH 3/3] utils/rpctrace: handle MACH_MSG_TYPE_PORT_SEND rights in trace_and_forward

Justus Winter, le Wed 11 Dec 2013 13:04:01 +0100, a écrit : > This allows one to rpctrace processes doing select(2). Ack. > * utils/rpctrace.c (trace_and_forward): Handle MACH_MSG_TYPE_PORT_SEND > rights. > --- > utils/rpctrace.c |4 > 1 file changed, 4 insertions(+)

Re: [PATCH 2/3] utils/rpctrace: generalize tracing code

Justus Winter, le Wed 11 Dec 2013 13:04:00 +0100, a écrit : > Currently, rpctrace dies if a tracee uses select(2) because it asserts > that reply_type is a MACH_MSG_TYPE_PORT_SEND_ONCE right. Generalize > the code surrounding the failing assertion. Ack. > * utils/rpctrace.c (trace

Re: [PATCH 1/3] utils/rpctrace: generalize code in rewrite_right

Justus Winter, le Wed 11 Dec 2013 13:03:59 +0100, a écrit : > * utils/rpctrace.c (rewrite_right): Generalize the code so we can use > rewrite_right to rewrite MACH_MSG_TYPE_PORT_SEND rights for non-rpc ports. Ack. > --- > utils/rpctrace.c |4 +--- > 1 file changed, 1 insertion(+), 3 deletion

  1   2   3   >