AMERICA INTERNATIONAL LOGISTICS（SHENZHEN） CO.,LTD
Dear Sir/Madam,
Good day! I'm kiko from ShenZhen China. I am working as forwarder in
Guangdong
port(Shenzhen,Guangzhou,Foshan port and so on.) for such long time, always
provide the
best
On 11/10, Roland McGrath wrote:
This change affects ia64, microblaze, parisc, powerpc, sh. They pass
nonzero step argument to tracehook but since it was ignored the tracee
reports via ptrace_notify(), this is not right and not consistent.
This could be more explicit about the details of
Well, ptrace_report_syscall() checks current-exit_code after
ptrace_notify() and does send_sig(). But yes, PTRACE_SETSIGINFO is
doesn't work.
Oh, right. Aside from PTRACE_SETSIGINFO, it's more subtly wrong in that it
generates a new signal (to be seen again by ptrace) rather than delivering
On 11/10, Roland McGrath wrote:
Ok. I realize it's largely separate, but I think we want to hash through
this along with the other set of after-report-behavior problems.
Also, it doesn't seem sensible to fiddle with utrace_report_syscall_entry
separate from resolving UTRACE_SYSCALL_RESUMED
I saw you have utrace-syscall-resumed branch but never looked at it.
For those not concerned with its purpose, there is one thing you must
know. Every report_syscall_entry callback must do:
if (utrace_syscall_action(action) == UTRACE_SYSCALL_RESUMED)
return
