Re: Missing PT_READ_U
[EMAIL PROTECTED] writes:
}Julian Elischer's diff as applied to the 4.5-RELEASE included
}below. With this change ups-3.37-beta4 compiled unchanged.
}
}But note that you still can't change any registers. If
}PT_WRITE_U is added back to the FreeBSD-4.x branch, no change
}is necessary to ups. So how about it, Peter Wemm?
I'm actually getting crashes in ups (on 4.5, compiled on 4.4) whenever the
debugged program receives a signal. I assume putting back PT_READ_U
will be sufficient to fix this?
}The other alternative is to change ups to understand
}PT_{SET,GET}{REGS,FPREGS} -- this would be needed for
}FreeBSD-5 in any case. But this is not a quick change as ups
}uses PTRACE_{PEEK,POKE}USER for dealing with registers and
}signals and these need to be replaced something more
}discriminating. I took a quick look at it but then got
}distracted. Also, not every arch. has separate FP regs and I
}didn't look deep enough in ups to figure out how to add
}machine dependent code like this.
Hopefully some enterprising young programmer in the ups camp will be
able to help out (when an alternate interface exists - is it in -current
now?). Unfortunately, I don't have knowledge to hack inside ups to that
degree.
C
Callum Gibson [EMAIL PROTECTED]
Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620
### The opinions in this message are mine and not Deutsche's ###
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing PT_READ_U
> }> As the culprit behind PT_READ_U's demise, I'm willing to dive in
> }> and help here if needed.
> }Thanks but Julian sent me a patch for 4.5 that seems to work
> }with no changes in ups. Would be nice if PT_READ_U is put
> }back in 4.x.
>
> As a followup to this old thread (and as the poster of the original
> question on the ups mailing list in late Feb) I note there has still
> been no change on the RELENG_4 branch to fix this. Could we have the
> patch posted here at least so other people can use ups again (with
> signals)? I'd just apply a reverse patch from kern/sys_process.c 1.51.2.2
> to 1.51.2.1 except that I don't know if other files (apart from sys/ptrace.h)
> have been affected.
Julain Elischer's diff as applied to the 4.5-RELEASE included
below. With this change ups-3.37-beta4 compiled unchanged.
But note that you still can't change any registers. If
PT_WRITE_U is added back to the FreeBSD-4.x branch, no change
is necessary to ups. So how about it, Peter Wemm?
The other alternative is to change ups to understand
PT_{SET,GET}{REGS,FPREGS} -- this would be needed for
FreeBSD-5 in any case. But this is not a quick change as ups
uses PTRACE_{PEEK,POKE}USER for dealing with registers and
signals and these need to be replaced something more
discriminating. I took a quick look at it but then got
distracted. Also, not every arch. has separate FP regs and I
didn't look deep enough in ups to figure out how to add
machine dependent code like this.
-- bakul
Index: sys/ptrace.h
===
RCS file: /home/ncvs/src/sys/sys/ptrace.h,v
retrieving revision 1.10.2.1
diff -u -r1.10.2.1 ptrace.h
--- sys/ptrace.h3 Oct 2001 06:55:43 - 1.10.2.1
+++ sys/ptrace.h1 Mar 2002 21:52:57 -
@@ -40,7 +40,7 @@
#definePT_TRACE_ME 0 /* child declares it's being traced */
#definePT_READ_I 1 /* read word in child's I space */
#definePT_READ_D 2 /* read word in child's D space */
-/* was PT_READ_U 3* read word in child's user structure */
+#definePT_READ_U 3 /* read word in child's user structure */
#definePT_WRITE_I 4 /* write word in child's I space */
#definePT_WRITE_D 5 /* write word in child's D space */
/* was PT_WRITE_U 6* write word in child's user structure */
Index: kern/sys_process.c
===
RCS file: /home/ncvs/src/sys/kern/sys_process.c,v
retrieving revision 1.51.2.3
diff -u -r1.51.2.3 sys_process.c
--- kern/sys_process.c 22 Jan 2002 17:22:59 - 1.51.2.3
+++ kern/sys_process.c 1 Mar 2002 23:45:18 -
@@ -257,6 +257,7 @@
case PT_READ_I:
case PT_READ_D:
+ case PT_READ_U:
case PT_WRITE_I:
case PT_WRITE_D:
case PT_CONTINUE:
@@ -413,6 +417,33 @@
}
return (error);
+ case PT_READ_U:
+ if ((uintptr_t)uap->addr > UPAGES * PAGE_SIZE -
+sizeof(int)) {
+ return EFAULT;
+ }
+ if ((uintptr_t)uap->addr & (sizeof(int) - 1)) {
+ return EFAULT;
+ }
+ if (ptrace_read_u_check(p,(vm_offset_t) uap->addr,
+ sizeof(int))) {
+ return EFAULT;
+ }
+ error = 0;
+ PHOLD(p); /* user had damn well better be incore!*/
+ if (p->p_flag & P_INMEM) {
+ p->p_addr->u_kproc.kp_proc = *p;
+ fill_eproc (p, &p->p_addr->u_kproc.kp_eproc);
+ curp->p_retval[0] = *(int *)
+ ((uintptr_t)p->p_addr +
+ (uintptr_t)uap->addr);
+ } else {
+ curp->p_retval[0] = 0;
+ error = EFAULT;
+ }
+ PRELE(p);
+ return error;
+
case PT_KILL:
uap->data = SIGKILL;
goto sendsig; /* in PT_CONTINUE above */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing PT_READ_U
Bakul Shah writes: }> As the culprit behind PT_READ_U's demise, I'm willing to dive in }> and help here if needed. }Thanks but Julian sent me a patch for 4.5 that seems to work }with no changes in ups. Would be nice if PT_READ_U is put }back in 4.x. As a followup to this old thread (and as the poster of the original question on the ups mailing list in late Feb) I note there has still been no change on the RELENG_4 branch to fix this. Could we have the patch posted here at least so other people can use ups again (with signals)? I'd just apply a reverse patch from kern/sys_process.c 1.51.2.2 to 1.51.2.1 except that I don't know if other files (apart from sys/ptrace.h) have been affected. Ta. C Callum Gibson [EMAIL PROTECTED] Global Markets IT, Deutsche Bank, Australia 61 2 9258 1620 ### The opinions in this message are mine and not Deutsche's ### To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing PT_READ_U
Bakul Shah wrote:
>
> > As the culprit behind PT_READ_U's demise, I'm willing to dive in
> > and help here if needed.
>
> Thanks but Julian sent me a patch for 4.5 that seems to work
> with no changes in ups. Would be nice if PT_READ_U is put
> back in 4.x.
Just a quick comment Peter..
I was thinking we could stuff PT_READ_U back in for 4.x to keep UPS
going till we sort out the Ptrace API for 5.0 (which we need to do
soon because it's the next stumbling block.)
and then retrofit the new interface to 4.6(?) when we know what it
is rather than doing it twice..
I know that PT_READ_U is ugly and not really correct for rforked processes but
it probably can stay in 4.x for a little without doing any damage.
>
[...]
> - should be able to get at additional registers (SSE etc. on x86).
> - I'd just merge access to all registers in one register
> space. This allows you to access any special or additional
> registers intel/amd may throw at you (ditto for ppc)
> without having to add more request codes. This is why
> READ_U/WRITE_U were so useful.
yes but if we changed the frame layout (which we could have done in
the kernel at any time) you lose.
> - would be nice if the old interface of just returning one
> word was put back even for registers. Typically you access
> a very small number in a debugger (more typically never).
> - May be for reading registers there is some value in a
> read-all register interface but hardly ever for writing.
> - Need a way to find out what threads exist and may be in
> what state (if 5.x had a u-page, this would be part of
> it!).
ummm one u page N threads.. that is why U page is dying..much
of the information init needs to be duplicated PER thread
(in the kernel)
> - Need PT_{ATTACH,DETACH,CONTINUE}_THREAD to deal with kernel
> threads. Some sort of thread-id would be handy for this.
> [But I don't know how you find a particular thread]
Threads are transitory from the point of view of the kernel
you have just enough threads as you need to run the number of system
calls you have outstanding. if you are totally in user space (even on
N processors then theoretically you have no threads in the kernel so
the kernel has no threads assigned to you. (Actually it has N
held to one side reserved for you but theoretically they are only there
as a cache. On the other hand the kernel is not informed at all about how many
threads are running in the userland. and theoretically the userland thread
scheduler might switch through 100 userland threads without entering the kernel
once so teh kernel doesn't know if there are 100 or 1 threads defined in
userland. All it knows is that when it retunred to userland aftera syscall
blocked..
SOMETHING did another syscall :-)
> - On a breakpoint a number of threads may stop -- if you
> allow other threads to proceed while the first thread at a
> bkpt is stopped. Need an ability to report this as well as
> continue/step any subset of these threads.
The whole ptrace interfacestarts to fall apart here.
> - Inserting debugging code that is run by a particular thread
> and no one else can be tricky [ability to insert code is
> one of the strengths of ups].
you'd have to nsert a breakpoint and CONDITIONALLY
allow the thread to run the new or old code according to which it was.
> - All this gets somewhat trickier (or impossible) to
> implement if you allow threads to run on multiple
> processors!
yep
> - If all this is done, it should be not too hard to add
> support (in a debugger) for debugging multi-process apps.
> - Need to look at how multi-threaded apps are debugged on
> other OSes and learn from that as well.
> - Need to experiment before settling on an interface.
>
> -- bakul
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +-->x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing PT_READ_U
> As the culprit behind PT_READ_U's demise, I'm willing to dive in
> and help here if needed.
Thanks but Julian sent me a patch for 4.5 that seems to work
with no changes in ups. Would be nice if PT_READ_U is put
back in 4.x.
Now that I think about it, ups will need to be fixed up since
the ability to write registers is lost with PT_WRITE_U gone
(have to use PT_SETREGS). If you want to put PT_WRITE_U back
in 4.5, I wouldn't complain;-)
> Incidently, PT_READ_U didn't actually work for the case where the
> signal handlers were shared between rfork()'ed processes.
Hmm... Probably neither does ups:-)
> Do you have any suggestions as to how PT_GET/SETSIGSTATE should look and
> feel? UPS's requirements seem pretty trivial (ie: return the handler
> for a given signal number), but that feels a bit minimalistic given that
> we have flags and a mask per signal as well. There is also the signal
> mask as well (masks are 128 bit).
I just copy struct sigacts in my code for this. There is no
PT_SETSIGSTATE (that would require a whole bunch of checking
for very little gain).
> On the other hand, maybe we should just keep it simple for ptrace() since
> the API is so limited.
There is time to think through API changes for 5.x. Reporting
signal state is a small part of this! Some random thoughts:
- should be able to get at additional registers (SSE etc. on x86).
- I'd just merge access to all registers in one register
space. This allows you to access any special or additional
registers intel/amd may throw at you (ditto for ppc)
without having to add more request codes. This is why
READ_U/WRITE_U were so useful.
- would be nice if the old interface of just returning one
word was put back even for registers. Typically you access
a very small number in a debugger (more typically never).
- May be for reading registers there is some value in a
read-all register interface but hardly ever for writing.
- Need a way to find out what threads exist and may be in
what state (if 5.x had a u-page, this would be part of
it!).
- Need PT_{ATTACH,DETACH,CONTINUE}_THREAD to deal with kernel
threads. Some sort of thread-id would be handy for this.
[But I don't know how you find a particular thread]
- On a breakpoint a number of threads may stop -- if you
allow other threads to proceed while the first thread at a
bkpt is stopped. Need an ability to report this as well as
continue/step any subset of these threads.
- Inserting debugging code that is run by a particular thread
and no one else can be tricky [ability to insert code is
one of the strengths of ups].
- All this gets somewhat trickier (or impossible) to
implement if you allow threads to run on multiple
processors!
- If all this is done, it should be not too hard to add
support (in a debugger) for debugging multi-process apps.
- Need to look at how multi-threaded apps are debugged on
other OSes and learn from that as well.
- Need to experiment before settling on an interface.
-- bakul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing PT_READ_U
Bakul Shah wrote:
> > Zap 'ptrace(PT_READ_U, ...)' and 'ptrace(PT_WRITE_U, ...)' since they
> > are a really nasty interface that should have been killed long ago
> > when 'ptrace(PT_[SG]ETREGS' etc came along. The entity that they
> > operate on (struct user) will not be around much longer since it
> > is part-per-process and part-per-thread in a post-KSE world.
>
> Yeah I saw that before sending out my query. This should've
> waited until after KSE is in place.
>
> > the uarea is pretty much a shadow of its former self
> > The fields have been scattered across two structures.
> >
> > What is ups trying to find out?
>
> Signal handling state of the process being debugged (whether
> ignored/caught etc).I haven't dug deeper into it so I
> don't know why it wants that but it seems to be pretty deeply
> wired in.
>
> > There are other ways to get all the information in question.
>
> There isn't. I don't think procfs will give me that either.
> May be PT_{SET,GET}SIGSTATE should be added?
As the culprit behind PT_READ_U's demise, I'm willing to dive in
and help here if needed.
Incidently, PT_READ_U didn't actually work for the case where the
signal handlers were shared between rfork()'ed processes.
Do you have any suggestions as to how PT_GET/SETSIGSTATE should look and
feel? UPS's requirements seem pretty trivial (ie: return the handler
for a given signal number), but that feels a bit minimalistic given that
we have flags and a mask per signal as well. There is also the signal
mask as well (masks are 128 bit).
On the other hand, maybe we should just keep it simple for ptrace() since
the API is so limited.
> BTW, what is being added to allow debugging a post-KSE world
> process?
>
> -- bakul
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing PT_READ_U
On Thu, 28 Feb 2002, Bakul Shah wrote:
> > Zap 'ptrace(PT_READ_U, ...)' and 'ptrace(PT_WRITE_U, ...)' since they
> > are a really nasty interface that should have been killed long ago
> > when 'ptrace(PT_[SG]ETREGS' etc came along. The entity that they
> > operate on (struct user) will not be around much longer since it
> > is part-per-process and part-per-thread in a post-KSE world.
>
> Yeah I saw that before sending out my query. This should've
> waited until after KSE is in place.
>
> > the uarea is pretty much a shadow of its former self
> > The fields have been scattered across two structures.
> >
> > What is ups trying to find out?
>
> Signal handling state of the process being debugged (whether
> ignored/caught etc).I haven't dug deeper into it so I
> don't know why it wants that but it seems to be pretty deeply
> wired in.
>
> > There are other ways to get all the information in question.
>
> There isn't. I don't think procfs will give me that either.
> May be PT_{SET,GET}SIGSTATE should be added?
>
> BTW, what is being added to allow debugging a post-KSE world
> process?
I'm planning on extending Ptrace.
There will need to be a ptrace command to specify
1/ which thread you want future ptrace commands to control
(e.g. single step),
2/ What you want the OTHER threads to do (e.g run as normal or stop)
The READ_U should be replaced by a specific SIGSTATE command as you
suggest I think.
It only reads it right?
>
> -- bakul
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing PT_READ_U
On Thu, 28 Feb 2002, Bakul Shah wrote:
> > Zap 'ptrace(PT_READ_U, ...)' and 'ptrace(PT_WRITE_U, ...)' since they
> > are a really nasty interface that should have been killed long ago
> > when 'ptrace(PT_[SG]ETREGS' etc came along. The entity that they
> > operate on (struct user) will not be around much longer since it
> > is part-per-process and part-per-thread in a post-KSE world.
>
> Yeah I saw that before sending out my query. This should've
> waited until after KSE is in place.
The u-area is already gone really...
>
> > the uarea is pretty much a shadow of its former self
> > The fields have been scattered across two structures.
> >
> > What is ups trying to find out?
>
> Signal handling state of the process being debugged (whether
> ignored/caught etc).I haven't dug deeper into it so I
> don't know why it wants that but it seems to be pretty deeply
> wired in.
>
> > There are other ways to get all the information in question.
>
> There isn't. I don't think procfs will give me that either.
> May be PT_{SET,GET}SIGSTATE should be added?
>
> BTW, what is being added to allow debugging a post-KSE world
> process?
>
> -- bakul
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing PT_READ_U
> Zap 'ptrace(PT_READ_U, ...)' and 'ptrace(PT_WRITE_U, ...)' since they
> are a really nasty interface that should have been killed long ago
> when 'ptrace(PT_[SG]ETREGS' etc came along. The entity that they
> operate on (struct user) will not be around much longer since it
> is part-per-process and part-per-thread in a post-KSE world.
Yeah I saw that before sending out my query. This should've
waited until after KSE is in place.
> the uarea is pretty much a shadow of its former self
> The fields have been scattered across two structures.
>
> What is ups trying to find out?
Signal handling state of the process being debugged (whether
ignored/caught etc).I haven't dug deeper into it so I
don't know why it wants that but it seems to be pretty deeply
wired in.
> There are other ways to get all the information in question.
There isn't. I don't think procfs will give me that either.
May be PT_{SET,GET}SIGSTATE should be added?
BTW, what is being added to allow debugging a post-KSE world
process?
-- bakul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing PT_READ_U
On Wed, 27 Feb 2002, Bakul Shah wrote: > Now that ptrace(PT_READ_U, ...) has been excised how does one > find out what actions are registered for various signals? > The ups debugger needs this. Please see > /usr/ports/devel/ups-debug/work/ups-3.35-beta13/ups/ao_pt_uarea.c:632 > > Thanks! > Here's the commit message in question: Revision 1.69 / (download) - annotate - [select for diffs], Wed Aug 8 05:25:07 2001 UTC (6 months, 3 weeks ago) by peter Branch: MAIN CVS Tags: KSE_PRE_MILESTONE_2 Changes since 1.68: +1 -44 lines Diff to previous 1.68 (colored) Zap 'ptrace(PT_READ_U, ...)' and 'ptrace(PT_WRITE_U, ...)' since they are a really nasty interface that should have been killed long ago when 'ptrace(PT_[SG]ETREGS' etc came along. The entity that they operate on (struct user) will not be around much longer since it is part-per-process and part-per-thread in a post-KSE world. gdb does not actually use this except for the obscure 'info udot' command which does a hexdump of as much of the child's 'struct user' as it can get. It carries its own #defines so it doesn't break compiles. this pretty much says it.. the uarea is pretty much a shadow of its former self The fields have been scattered across two structures. What is ups trying to find out? There are other ways to get all the information in question. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Missing PT_READ_U
Now that ptrace(PT_READ_U, ...) has been excised how does one find out what actions are registered for various signals? The ups debugger needs this. Please see /usr/ports/devel/ups-debug/work/ups-3.35-beta13/ups/ao_pt_uarea.c:632 Thanks! -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
