Re: [PATCH v2 1/2] xattr: use printstr_ex instead of print_quoted_string

[Mike Frysinger]

On 23 Dec 2016 08:28, JingPiao Chen wrote:
> Could I ask a question? All the string even in struct should comply with -s
> option?
> All the string should NUL terminate? Thanks.

it probably depends on the syscall ... not all buffers are NUL terminated.
it would help if you quoted a specific syscall.
-mike


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: A: sched_xetattr.test fails consistently on aarch64

[Mike Frysinger]

On 14 Mar 2017 00:57, Mike Frysinger wrote:
> so there's a disagreement in the overall system somewhere.
> i'd assume either the kernel's implementation of access_ok,
> or gcc's handling of the inline assembly.
> 
> once i have access to a local system and reduce a bit more,
> i'll file some upstream bugs.

hmm, looks like it's this old bug:
https://gcc.gnu.org/PR63359

i have a fix locally to the kernel, but i need to test it first.
-mike


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: A: sched_xetattr.test fails consistently on aarch64

[Mike Frysinger]

On 14 Mar 2017 00:13, Dmitry V. Levin wrote:
> sched_xetattr.test introduced by commit v4.16-10-gf31755f
> (tests: check decoding of sched_[gs]etattr corner cases)
> consistently fails on aarch64.
> 
> At the same time the test passes on all other architectures
> where strace is being tested regularly, both 64-bit
> (alpha, ia64, mips64, ppc64, s390x, sparc64, x86_64)
> and 32-bit (arm, hppa, mips, ppc, s390, sparc, x86).
> 
> The test failure is visible on debian, fedora, and obs farms:
> 
> http://www.einval.com/debian/strace/build-logs/arm64/2017-03-13-040306-log-asachi-TESTFAIL.txt
> https://kojipkgs.fedoraproject.org//work/tasks/5517/18365517/build.log
> https://build.opensuse.org/public/build/home:ldv_alt/openSUSE_Factory_ARM/aarch64/strace/_log
> 
> The part of test that fails on aarch64 is this harmless syscall:
> 
> sys_sched_getattr(F8ILL_KULONG_MASK, (unsigned long) attr,
> F8ILL_KULONG_MASK | sizeof(*attr), F8ILL_KULONG_MASK);
> 
> I wouldn't be very much surprised if the test has hit some subtle kernel
> bug on aarch64.

it's failing on my system.  here's my setup:
kernel 3.18 / gcc 4.9 / binutils 2.25:
Linux koi 3.18.0-13745-gf83aa11 #1 SMP PREEMPT Thu Feb 16 16:56:32 PST 
2017 aarch64 GNU/Linux
aarch64-cros-linux-gnu-gcc 
(4.9.2_cos_gg_4.9.2-r150-41f3e25635616c067b9ee272304e6f86ac8ee9db_4.9.2-r150) 
4.9.x 20150123 (prerelease)
GNU ld 
(binutils-2.25.51-r63-082ed0f10cf59b53381cefda2f90247e2a81015b_cos_gg) 
2.25.51.20141117
userland is built with slightly newer tools:
gcc (Gentoo 4.9.4 p1.0, pie-0.6.4) 4.9.4
GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
i haven't had a chance yet to build+boot a newer kernel.  hopefully next week.

seems like it's the F8ILL_KULONG_MASK in the size field.
if i drop that, the test passes.  which doesn't make sense ...

sched_getattr in arm64 is wired up to the common code directly:
arch/arm64/kernel/sys.c:
#define __SYSCALL(nr, sym)  [nr] = sym,
void * const sys_call_table[__NR_syscalls] __aligned(4096) = {
[0 ... __NR_syscalls - 1] = sys_ni_syscall,
#include 
};

and then down the rabbit hole we go until we hit asm-generic:
arch/arm64/include/asm/unistd.h:
#include 
arch/arm64/include/uapi/asm/unistd.h:
#include 
include/asm-generic/unistd.h:
#include 
include/uapi/asm-generic/unistd.h:
#define __NR_sched_getattr 275
__SYSCALL(__NR_sched_getattr, sys_sched_getattr)

which means __NR_sched_getattr should take us directly to the C entry
point of sys_sched_getattr which is here:
kernel/sched/core.c:
SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct sched_attr __user *, 
uattr,
unsigned int, size, unsigned int, flags)

so it wants unsigned int (32-bit), but strace is giving it unsigned long
(64-bit) with the high 32-bits filled.

glibc's syscall wrapper naturally passes along the full registers.
with aarch64, the assembly notion is that x regs are the full 64-bit
while w regs are the lower 32-bits.  so here we're moving 64-bits.
/usr/include/unistd.h:
extern long int syscall (long int __sysno, ...) __THROW;
sysdeps/unix/sysv/linux/aarch64/syscall.S:
ENTRY (syscall)
uxtwx8, w0
mov x0, x1
mov x1, x2
mov x2, x3
mov x3, x4
mov x4, x5
mov x5, x6
mov x6, x7
svc 0x0
cmn x0, #4095
b.cs1f
RET
1:
b   SYSCALL_ERROR
PSEUDO_END (syscall)

let's look at the kernel source first:
kernel/sched/core.c:
SYSCALL_DEFINE4(sched_getattr, pid_t, pid, struct sched_attr __user *, uattr,
unsigned int, size, unsigned int, flags)
{
struct sched_attr attr = {
.size = sizeof(struct sched_attr),
};
struct task_struct *p;
int retval;

if (!uattr || pid < 0 || size > PAGE_SIZE ||
size < SCHED_ATTR_SIZE_VER0 || flags)
return -EINVAL;

rcu_read_lock();
p = find_process_by_pid(pid);   
retval = -ESRCH;
if (!p)
goto out_unlock;

retval = security_task_getscheduler(p);
if (retval)
goto out_unlock;

attr.sched_policy = p->policy;
if (p->sched_reset_on_fork)
attr.sched_flags |= SCHED_FLAG_RESET_ON_FORK;
if (task_has_dl_policy(p))
__getparam_dl(p, );
else if (task_has_rt_policy(p))
attr.sched_priority = p->rt_priority;
else
attr.sched_nice = task_nice(p);

rcu_read_unlock();

retval = sched_read_attr(uattr, , size);
return retval;

out_unlock:
rcu_read_unlock();
return retval;
}

static int sched_read_attr(struct sched_attr __user *uattr,
   struct sched_attr *attr,
   unsigned int usize)
{   
int ret;

if (!access_ok(VERIFY_WRITE, uattr, usize))
return -EFAULT;

/*
 * If we're handed a smaller struct than we know of,
 * ensure all the unknown bits are 0 - i.e. old
 

Re: A: sched_xetattr.test fails consistently on aarch64

[Mike Frysinger]

On 14 Mar 2017 00:13, Dmitry V. Levin wrote:
> However, I'm not an aarch64 expert myself, nor do I have the appropriate
> aarch64 hardware to investigate, so this issue is not going to be solved
> without your help.

fwiw, i should have a Gentoo system available for you to remote access
in the next month
-mike


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Patch: Fix libunwind segfault when -p is passed before -k

[Mike Frysinger]

On 08 Dec 2016 10:00, Sean Stangl wrote:
> +#ifdef USE_LIBUNWIND
> +static void
> +late_unwind_tcb_init()

this needs a "(void)" in the def
-mike


signature.asc
Description: Digital signature
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: NOMMU bogus syscall return values

[Mike Frysinger]

On 02 Mar 2016 20:28, Rich Felker wrote:
> On Thu, Mar 03, 2016 at 04:01:21AM +0300, Dmitry V. Levin wrote:
> > On Mon, Feb 29, 2016 at 05:59:44PM -0500, Mike Frysinger wrote:
> > > On 29 Feb 2016 15:56, Rich Felker wrote:
> > [...]
> > > > The attached (very hackish at the moment) patch makes it work for me
> > > > by eliminating the need to define NOMMU_SYSTEM to 1 and using clone()
> > > > with CLONE_VM and a new stack for the child, instead of vfork. I see
> > > > some potential issues that need to be addressed before this could be
> > > > made into a proper solution, though:
> > > > 
> > > > 1. I'm not sure if all NOMMU systems strace supports have clone. If
> > > >so, I think vfork could be dropped completely and this used
> > > >instead.
> > > 
> > > uClibc has long required clone, so seems safe to assume it exists
> > 
> > strace assumes that PTRACE_SETOPTIONS works, which essentially means that
> > linux kernel >= 2.6 is required.  On some architectures, newer kernel is
> > required (e.g. >= 2.6.15 on mips for PTRACE_GETREGS support).  I don't
> > know for sure whether all supported NOMMU systems have CLONE_VM, but
> > I agree with Mike it seems safe to assume they do.
> 
> I was merely unaware whether strace supported any non-Linux systems.
> Linux has had clone/CLONE_VM since basically forever (2.0, maybe
> earlier) so if strace is Linux-only this is a non-issue. Should I try
> to prepare a patch converting all the forks to clone so that NOMMU is
> not a special case? What should be done about daemonized tracer mode?

strace used to support more than Linux, but i think since no one has been
keeping up other OS's, we just wait for someone to step up.  not sure how
Dmitry feels about it.  we certainly don't do any build/run tests :).
-mike


signature.asc
Description: Digital signature
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: NOMMU bogus syscall return values

[Mike Frysinger]

On 29 Feb 2016 15:56, Rich Felker wrote:
> I've been trying to use strace on a NOMMU system (sh2) and have been
> experiencing an issue where the return value (read from r0) and args
> 5/6 (r0,r1) are bogus, making the output much less useful than it
> otherwise would be. The problem seems to be that the tracer is
> desynced with the child's STOP parity and is confusing syscall
> entry/exit, probably due to exec_or_die not stopping itself before
> exec to sync with the parent. Even if not for the bug I'm
> experiencing, this seems to be problematic in that early syscalls in
> the child can be lost (I've actually hit that problem too).

on Blackfin, strace was always flaky beyond the first process.
i never got around to tracking it down.

> The attached (very hackish at the moment) patch makes it work for me
> by eliminating the need to define NOMMU_SYSTEM to 1 and using clone()
> with CLONE_VM and a new stack for the child, instead of vfork. I see
> some potential issues that need to be addressed before this could be
> made into a proper solution, though:
> 
> 1. I'm not sure if all NOMMU systems strace supports have clone. If
>so, I think vfork could be dropped completely and this used
>instead.

uClibc has long required clone, so seems safe to assume it exists
-mike


signature.asc
Description: Digital signature
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: syscall_4294967295

[Mike Frysinger]

On 15 Feb 2016 17:50, Dmitry V. Levin wrote:
> On Mon, Feb 15, 2016 at 09:30:18AM -0500, Mike Frysinger wrote:
> > On 15 Feb 2016 15:21, Dmitry V. Levin wrote:
> > > On Mon, Feb 15, 2016 at 12:12:09PM +0100, Pas wrote:
> > > > Thanks for the quick response and for the hint! After testing with
> > > > -fveseccomp,prctl
> > > > it turns out that:
> > > > 
> > > > docker-engine 1.10.1-0~wily uses seccomp (prctl PR_SET_SECCOMP,
> > > > SECCOMP_MODE_FILTER and PR_CAPBSET_DROP ...), whereas 1.10.1-0~jessie
> > > > doesn't. Though eventually by default Docker will filter out (almost 
> > > > all?)
> > > > syscalls:
> > > > https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
> > > 
> > > On entering syscall, seccomp kernel hooks are executed before ptrace
> > > kernel hooks.  As result, when some syscall is blocked by seccomp filter
> > > using SECCOMP_RET_ERRNO statement, on many architectures including x86 and
> > > x86_64 the syscall number is clobbered and strace sees -1 in its place.
> > > 
> > > You can play with strace/tests/seccomp.c and see it yourself.
> > 
> > would PTRACE_O_TRACESECCOMP help here ?
> 
> Only for SECCOMP_RET_TRACE actions.

oh i misread ... i was thinking it was for all ret operations.
can we get the seccomp core to save its original state in a way
we can get at later, perhaps via a new PTRACE_GETSECCOMPDATA ?
that'd tell us which SECCOMP_RET_xxx was used and the value that
was in there before.  we would need a new PTRACE_EVENT_xxx so we
don't have to run it all the time.
-mike


signature.asc
Description: Digital signature
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: syscall_4294967295

[Mike Frysinger]

On 15 Feb 2016 15:21, Dmitry V. Levin wrote:
> On Mon, Feb 15, 2016 at 12:12:09PM +0100, Pas wrote:
> > Thanks for the quick response and for the hint! After testing with
> > -fveseccomp,prctl
> > it turns out that:
> > 
> > docker-engine 1.10.1-0~wily uses seccomp (prctl PR_SET_SECCOMP,
> > SECCOMP_MODE_FILTER and PR_CAPBSET_DROP ...), whereas 1.10.1-0~jessie
> > doesn't. Though eventually by default Docker will filter out (almost all?)
> > syscalls:
> > https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
> 
> On entering syscall, seccomp kernel hooks are executed before ptrace
> kernel hooks.  As result, when some syscall is blocked by seccomp filter
> using SECCOMP_RET_ERRNO statement, on many architectures including x86 and
> x86_64 the syscall number is clobbered and straces sees -1 in its place.
> 
> You can play with strace/tests/seccomp.c and see it yourself.

would PTRACE_O_TRACESECCOMP help here ?
-mike


signature.asc
Description: Digital signature
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: using ptrace to cancel a syscall on sparc

[Mike Frysinger]

On 19 Jan 2016 15:10, David Miller wrote:
> From: Mike Frysinger <vap...@gentoo.org>
> Date: Mon, 18 Jan 2016 06:32:30 -0500
> 
> > looks like the bug is in arch/sparc/kernel/syscalls.S:linux_syscall_trace32
> > (and linux_syscall_trace).  they don't reload the args from the pt_regs
> > struct after calling syscall_trace_enter.  i put in a small hack:
> 
> Mike, please give this patch a test, thanks!

it fixes my reduced test case, and seems to fix my original testcase
(a program that uses ptrace to monitor fs behavior in static progs).
thanks !

Tested-by: Mike Frysinger <vap...@gentoo.org>
-mike


signature.asc
Description: Digital signature
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: using ptrace to cancel a syscall on sparc

[Mike Frysinger]

On 21 Dec 2015 02:31, Dmitry V. Levin wrote:
> On Sun, Dec 20, 2015 at 12:47:54AM -0500, Mike Frysinger wrote:
> > i've been playing with ptrace on sparc and trying to use it to watch and
> > cancel specific syscalls.  i have this working for other arches already.
> [...]
> > i'm having trouble with canceling of the syscall itself.  seems like
> > no matter what i stuff into o0, the kernel executes the unlink.  i've
> > tried tracing arch/sparc/kernel/syscalls.S and kernel/head_64.S, the
> > the entry is linux_sparc_syscall32 which calls linux_syscall_trace32,
> > but it seems like the o0 stuff doesn't seem to work for me.  my sparc
> > asm foo isn't strong enough to figure out what's going wrong :/.
> 
> Yes, sparc is odd in this respect: whatever you write to u_regs[] on
> entering syscall, it doesn't affect syscall number or syscall arguments.

looks like the bug is in arch/sparc/kernel/syscalls.S:linux_syscall_trace32
(and linux_syscall_trace).  they don't reload the args from the pt_regs
struct after calling syscall_trace_enter.  i put in a small hack:
linux_syscall_trace32:
callsyscall_trace_enter
 add%sp, PTREGS_OFF, %o0
brnz,pn %o0, 3f
 mov-ENOSYS, %o0
+
+   ldx [%sp + PTREGS_OFF + PT_V9_G1], %g1
+   cmp %g1, NR_syscalls
=   bgeu,pn %xcc, 3f
+mov-ENOSYS, %o0
+
srl %i0, 0, %o0
srl %i4, 0, %o4
...

it's enough for my use case (cancel the call), but it's not entirely correct.
i think it needs to re-initialize %l7 with the final syscall pointer via the
syscall table, and it needs to reload PT_V9_I{0..5}.  i have no idea which
regs need stuffing though, especially in light of the %l7 optimization.  and
i'm not familiar at all with the apparent parallelism via IEU0/IEU1 groups.
so i won't bother with trying to write a full patch.  hopefully sparc guys
will notice & post a fix ;).

i'm attaching my simple test in case it helps.  just do:
  $ gcc ptrace-test.c && ./a.out
the logging output should indicate when things are passing.
-mike
#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define U_REG_G1 0
#define U_REG_O0 7

static pid_t trace_pid;

static long _do_ptrace(enum __ptrace_request request, const char *srequest, void *addr, void *data)
{
	long ret;
 try_again:
	errno = 0;
	ret = ptrace(request, trace_pid, addr, data);
	if (ret == -1) {
		/* Child hasn't gotten to the next marker yet ? */
		if (errno == ESRCH) {
			int status;
			if (waitpid(trace_pid, , 0) == -1) {
/* nah, it's dead ... should we whine though ? */
_exit(0);
			}
			sched_yield();
			goto try_again;
		} else if (!errno)
			if (request == PTRACE_PEEKDATA ||
			request == PTRACE_PEEKTEXT ||
			request == PTRACE_PEEKUSER)
return ret;

		err(1, "do_ptrace: ptrace(%s, ..., %p, %p)", srequest, addr, data);
	}
	return ret;
}
#define do_ptrace(request, addr, data) _do_ptrace(request, #request, addr, data)

static void trace_child_signal(int signo, siginfo_t *info, void *context)
{
#if 0
	warnx("got sig %s(%i): code:%s(%i) status:%s(%i)",
		strsignal(signo), signo,
		"---", info->si_code,
		strsignal(info->si_status), info->si_status);
#endif

	switch (info->si_code) {
		case CLD_DUMPED:
		case CLD_KILLED:
			_exit(128 + info->si_status);

		case CLD_EXITED:
			_exit(info->si_status);

		case CLD_TRAPPED:
			switch (info->si_status) {
case SIGSTOP:
	kill(trace_pid, SIGCONT);
case SIGTRAP:
case SIGCONT:
	return;
			}

			/* For whatever signal the child caught, let's ignore it and
			 * continue on.  If it aborted, segfaulted, whatever, that's
			 * its problem, not ours, so don't whine about it.  We just
			 * have to be sure to bubble it back up.  #265072
			 */
			do_ptrace(PTRACE_CONT, NULL, (void *)(long)info->si_status);
			return;
	}

	errx(1, "unhandled signal case");
}

static const char *lookup_syscall(long nr)
{
	switch (nr) {
#define X(n) case SYS_##n: return #n;
	X(access)
	X(brk)
	X(close)
	X(creat)
	X(dup)
	X(exit)
	X(exit_group)
	X(fstat64)
	X(mmap)
	X(mprotect)
	X(munmap)
	X(open)
	X(read)
	X(uname)
	X(unlink)
	X(write)
#undef X
	}
	return "";
}

void child_main(void)
{
	char test_file[] = ".test.flag";
	char msg[] = "child: you should see two of these\n";
	int fd = dup(2);

	unlink(test_file);
	write(fd, msg, sizeof(msg));

	/* Marker for the parent to watch. */
	errno = 0;
	close(12345);
	fprintf(stderr, "child: close marker (should be EPERM): %m\n");
	errno = 0;
	close(fd);
	fprintf(stderr, "child: real close (should be EPERM): %m\n");
	errno = 0;
	write(fd, msg, sizeof(msg));
	fprintf(stderr, "child: write (should be success): %m\n");
	errno = 0;
	creat(test_file, 0660);
	f

using ptrace to cancel a syscall on sparc

[Mike Frysinger]

i've been playing with ptrace on sparc and trying to use it to watch and
cancel specific syscalls.  i have this working for other arches already.

the test is pretty simple:
 - call open("f", O_CREAT)
 - call unlink("f")
the tracer will watch for the unlink, and when it gets notified, stuffs
the syscall # with -1 (so it'll get skipped).  then when it gets called
a second time, it stuffs the exit with -1/EPERM.

i'm using PTRACE_GETREGS/PTRACE_SETREGS to read/write the regsets (and
i've swapped the addr/data args specifically for sparc).  i extract the
syscall # from g1 (u_regs[0]) and syscalls args from o0..o5 (u_regs[7]
through u_regs[12]).  this seems to be working fine.

when setting the return value, i set PSR_C in the psr register, and i
set o0 to EPERM.  seems to be working (the unlink function returns a
-1 and errno is EPERM).

i'm having trouble with canceling of the syscall itself.  seems like
no matter what i stuff into o0, the kernel executes the unlink.  i've
tried tracing arch/sparc/kernel/syscalls.S and kernel/head_64.S, the
the entry is linux_sparc_syscall32 which calls linux_syscall_trace32,
but it seems like the o0 stuff doesn't seem to work for me.  my sparc
asm foo isn't strong enough to figure out what's going wrong :/.
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 15 Dec 2015 00:03, Dmitry V. Levin wrote:
> On Mon, Dec 14, 2015 at 03:45:40PM -0500, Mike Frysinger wrote:
> > On 11 Dec 2015 06:30, Dmitry V. Levin wrote:
> > > On Thu, Dec 10, 2015 at 09:37:35PM -0500, Mike Frysinger wrote:
> [...]
> > > > vFAIL:  test;   x86_64  32-bit/LSB  linux-4.1.6 
> > > > kernel-headers-4.1.0   glibc-2.21  gcc-4.9.2
> > > > < times({tms_utime=22, tms_stime=17, tms_cutime=33, tms_cstime=26}) = 
> > > > 18446744071580810102
> > > > ---
> > > > > times({tms_utime=22, tms_stime=17, tms_cutime=33, tms_cstime=26}) = 
> > > > > 2166225782
> > > 
> > > Looks like a sign extension bug in libc.
> > > Is there any safe way on x32 to call times(2) directly?
> > 
> > time_t/clock_t/unsigned long long are 64bit in x32.
> 
> Yes, but the value returned by times syscall in this case is 2166225782.
> I suppose it's libc that sign-extended 2166225782 to 18446744071580810102.
> That's why I'd like to avoid libc wrapper and call times syscall
> directly.  Unfortunately, syscall() returns long which is not appropriate
> for times syscall on x32.

yes, it looks like a bug in glibc.  i'll follow up with them.

wrt syscall, i vaguely recall i raised that issue a while back,
but not sure what happened to it.  i'll have to dig it up again.

> > looks like strace doesn't like it when you call clock_gettime:
> > strace: syscall_228(...) in unsupported 64-bit mode of process PID=2565
> > 
> > which doesn't make sense as they're the same syscall for x86_64 and x32.
> 
> They are not exactly the same, as x32 syscalls have __X32_SYSCALL_BIT set.
> In this case libc must be invoking an x86_64 syscall instead of an x32 one.

strace should handle all the syscalls that are common between the two ABIs.
they literally route to the same location and process args in the same way.
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 15 Dec 2015 00:24, Dmitry V. Levin wrote:
> On Mon, Dec 14, 2015 at 03:45:40PM -0500, Mike Frysinger wrote:
> [...]
> > the older version of gawk used seems to be unhappy with the script.
> > when i run the command manually:
> > $ gawk -v VAR_NAME=mpers_target_var -v ARCH_FLAG=m32 -f ./mpers.awk 
> > mpers-m32/kernel_dirent.d2
> > #include 
> > typedef
> > Killed
> [...]
> > this is gawk-4.0.1, so i suspect you should be able to reproduce by 
> > installing
> > that version locally.  i'm attaching the mpers-m32/kernel_dirent.d2 in case 
> > it
> > helps.
> 
> It's not the version of gawk but contents of mpers-m32/kernel_dirent.d2
> that makes the script go into infinite recursion.  Looks like .d2 is wrong.
> Could you attach mpers-m32/kernel_dirent.d1 file, please?

done.  we probably should add a sanity check to the gawk script so
it asserts rather than OOMs.
-mike
Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:0xf0 (32-bit)
   Version:   4
   Abbrev Offset: 0x0
   Pointer Size:  4
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0xcd): GNU C 4.9.2 -m32 
-mtune=generic -march=x86-64 -gdwarf-4 -fstack-protector-strong
<10>   DW_AT_language: 1(ANSI C)
<11>   DW_AT_name: (indirect string, offset: 0x58): 
mpers-m32/kernel_dirent.c
<15>   DW_AT_comp_dir: (indirect string, offset: 0x11e): /root/strace
<19>   DW_AT_stmt_list   : 0x0
 <1><1d>: Abbrev Number: 2 (DW_TAG_base_type)
<1e>   DW_AT_byte_size   : 1
<1f>   DW_AT_encoding: 6(signed char)
<20>   DW_AT_name: (indirect string, offset: 0x14c): signed char
 <1><24>: Abbrev Number: 2 (DW_TAG_base_type)
<25>   DW_AT_byte_size   : 2
<26>   DW_AT_encoding: 5(signed)
<27>   DW_AT_name: (indirect string, offset: 0x158): short int
 <1><2b>: Abbrev Number: 3 (DW_TAG_base_type)
<2c>   DW_AT_byte_size   : 4
<2d>   DW_AT_encoding: 5(signed)
<2e>   DW_AT_name: int
 <1><32>: Abbrev Number: 2 (DW_TAG_base_type)
<33>   DW_AT_byte_size   : 8
<34>   DW_AT_encoding: 5(signed)
<35>   DW_AT_name: (indirect string, offset: 0x0): long long int
 <1><39>: Abbrev Number: 2 (DW_TAG_base_type)
<3a>   DW_AT_byte_size   : 1
<3b>   DW_AT_encoding: 8(unsigned char)
<3c>   DW_AT_name: (indirect string, offset: 0x1b): unsigned char
 <1><40>: Abbrev Number: 2 (DW_TAG_base_type)
<41>   DW_AT_byte_size   : 2
<42>   DW_AT_encoding: 7(unsigned)
<43>   DW_AT_name: (indirect string, offset: 0x139): short unsigned 
int
 <1><47>: Abbrev Number: 2 (DW_TAG_base_type)
<48>   DW_AT_byte_size   : 4
<49>   DW_AT_encoding: 7(unsigned)
<4a>   DW_AT_name: (indirect string, offset: 0xe): unsigned int
 <1><4e>: Abbrev Number: 2 (DW_TAG_base_type)
<4f>   DW_AT_byte_size   : 8
<50>   DW_AT_encoding: 7(unsigned)
<51>   DW_AT_name: (indirect string, offset: 0x84): long long 
unsigned int
 <1><55>: Abbrev Number: 2 (DW_TAG_base_type)
<56>   DW_AT_byte_size   : 4
<57>   DW_AT_encoding: 5(signed)
<58>   DW_AT_name: (indirect string, offset: 0xbe): long int
 <1><5c>: Abbrev Number: 2 (DW_TAG_base_type)
<5d>   DW_AT_byte_size   : 4
<5e>   DW_AT_encoding: 7(unsigned)
<5f>   DW_AT_name: (indirect string, offset: 0x72): long unsigned 
int
 <1><63>: Abbrev Number: 2 (DW_TAG_base_type)
<64>   DW_AT_byte_size   : 4
<65>   DW_AT_encoding: 7(unsigned)
<66>   DW_AT_name: (indirect string, offset: 0x162): sizetype
 <1><6a>: Abbrev Number: 2 (DW_TAG_base_type)
<6b>   DW_AT_byte_size   : 1
<6c>   DW_AT_encoding: 6(signed char)
<6d>   DW_AT_name: (indirect string, offset: 0xb9): char
 <1><71>: Abbrev Number: 4 (DW_TAG_array_type)
<72>   DW_AT_type: <0x6a>
<76>   DW_AT_sibling : <0x81>
 <2><7a>: Abbrev Number: 5 (DW_TAG_subrange_type)
<7b>   DW_AT_type: <0x63>
<7f>   DW_AT_upper_bound : 0
 <2><80>: Abbrev Number: 0
 <1><81>: Abbrev Number: 2 (DW_TAG_base_type)
<82>   DW_AT_byte_size   : 1
<83>   DW_AT_encoding: 2(boolean)
<84>   DW_AT_name: (indirect string, o

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 15 Dec 2015 00:59, Dmitry V. Levin wrote:
> On Mon, Dec 14, 2015 at 04:46:49PM -0500, Mike Frysinger wrote:
> > On 15 Dec 2015 00:24, Dmitry V. Levin wrote:
> > > On Mon, Dec 14, 2015 at 03:45:40PM -0500, Mike Frysinger wrote:
> > > [...]
> > > > the older version of gawk used seems to be unhappy with the script.
> > > > when i run the command manually:
> > > > $ gawk -v VAR_NAME=mpers_target_var -v ARCH_FLAG=m32 -f ./mpers.awk 
> > > > mpers-m32/kernel_dirent.d2
> > > > #include 
> > > > typedef
> > > > Killed
> > > [...]
> > > > this is gawk-4.0.1, so i suspect you should be able to reproduce by 
> > > > installing
> > > > that version locally.  i'm attaching the mpers-m32/kernel_dirent.d2 in 
> > > > case it
> > > > helps.
> > > 
> > > It's not the version of gawk but contents of mpers-m32/kernel_dirent.d2
> > > that makes the script go into infinite recursion.  Looks like .d2 is 
> > > wrong.
> > > Could you attach mpers-m32/kernel_dirent.d1 file, please?
> > 
> > done.
> 
> This is another mpers-m32/kernel_dirent.d1 file.  Broken
> mpers-m32/kernel_dirent.d2 mentions .debug_types section,
> so it has to be in the .d1 file as well.

sorry, i confused the x32 failures with the old glibc/x86_64 one.  here's
the files from the same build so i know i didn't screw it up ;).

this system is:
binutils-2.22
gcc-4.5.4
glibc-2.4
-mike


kernel_dirent.d1.gz
Description: Binary data


kernel_dirent.d2.gz
Description: Binary data


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 11 Dec 2015 06:30, Dmitry V. Levin wrote:
> On Thu, Dec 10, 2015 at 09:37:35PM -0500, Mike Frysinger wrote:
> > i haven't had a chance yet to triage these.
> > 
> > testing commit bab4ef4272cd2596c7390b34ea8acc086ee8fdb2 (v4.10-566-gbab4ef4)
> > 
> > native (build+tests):
> > vFAIL:  build;  x86_64  ??? linux-4.1.6 
> > kernel-headers-3.4.0   glibc-2.4   gcc-4.5.4
> > vFAIL:  build;  sparc64  ???  cross  kernel-headers-4.3.0  glibc-2.22  
> > gcc-4.6.4
> > ./mpers.sh: line 21: 18442 Killed  gawk -v 
> > VAR_NAME="$VAR_NAME" -v ARCH_FLAG="${ARCH_FLAG#-}" -f "$MPERS_AWK" 
> > "${f_d2}" > "${f_h}"
> 
> Was it an OOM killer in both cases?

the older version of gawk used seems to be unhappy with the script.
when i run the command manually:
$ gawk -v VAR_NAME=mpers_target_var -v ARCH_FLAG=m32 -f ./mpers.awk 
mpers-m32/kernel_dirent.d2
#include 
typedef
Killed

running it through strace shows that it keeps increasing the heap until it OOMs:
...
brk(0x9524e000) = 0x9524e000
brk(0x9526f000) = 0x9526f000
brk(0x95291000) = 0x95291000
brk(0x952b2000) = 0x952b2000
brk(0x952d4000) = 0x952d4000
brk(0x952f5000) = 0x952f5000
...

adding some debug statements to the script shows it gets into infinite recursion
with the what_is function:
#include 
typedef
what_is( 0x79 )
type_idx = {  }
special = { typedef }
what_is(  )
type_idx = {  }
special = {  }
what_is(  )
...repeats blank lookups forever...

this is gawk-4.0.1, so i suspect you should be able to reproduce by installing
that version locally.  i'm attaching the mpers-m32/kernel_dirent.d2 in case it
helps.

> > vFAIL:  test;   armv7l  32-bit/LSB  linux-3.4.0-vapier  
> > kernel-headers-3.18.0  glibc-2.21  gcc-4.9.3
> > Segmentation fault
> > inet-cmsg.test: failed test: ./inet-cmsg failed
> 
> tests/inet-cmsg.c sagfaulted, need more info.

yikes, this looks like a kernel bug :).  i'll try a newer one on that system
(i've got a 3.8 upgrade pending already).
[0.00] Unable to handle kernel NULL pointer dereference at virtual 
address 0080
[0.00] pgd = ec708000
[   80.00] *pgd=41dcc831, *pte=, *ppte=
[0.00] Internal error: Oops: 17 [#9] SMP ARM
...
[0.00] PC is at ip_options_echo+0x4c/0x410
[0.00] LR is at ip_options_echo+0x28/0x410
...
[0.00] [<80383ee8>] (ip_options_echo+0x4c/0x410) from [<80387e38>] 
(ip_cmsg_recv+0x1c8/0x204)
[0.00] [<80387e38>] (ip_cmsg_recv+0x1c8/0x204) from [<803a7e70>] 
(udp_recvmsg+0x334/0x374)
[0.00] [<803a7e70>] (udp_recvmsg+0x334/0x374) from [<803afe7c>] 
(inet_recvmsg+0x94/0xac)
[0.00] [<803afe7c>] (inet_recvmsg+0x94/0xac) from [<8034b160>] 
(sock_recvmsg+0xb0/0xd0)
[0.00] [<8034b160>] (sock_recvmsg+0xb0/0xd0) from [<8034c040>] 
(__sys_recvmsg+0x110/0x1c8)
[0.00] [<8034c040>] (__sys_recvmsg+0x110/0x1c8) from [<8034d1d0>] 
(sys_recvmsg+0x4c/0x78)
[0.00] [<8034d1d0>] (sys_recvmsg+0x4c/0x78) from [<8000e580>] 
(ret_fast_syscall+0x0/0x30)
[0.00] Code: e5d63022 e3c22001 e5969080 e353 (e5922080) 
...

> > vFAIL:  test;   x86_64  32-bit/LSB  linux-4.1.6 
> > kernel-headers-4.1.0   glibc-2.21  gcc-4.9.2
> > < times({tms_utime=22, tms_stime=17, tms_cutime=33, tms_cstime=26}) = 
> > 18446744071580810102
> > ---
> > > times({tms_utime=22, tms_stime=17, tms_cutime=33, tms_cstime=26}) = 
> > > 2166225782
> 
> Looks like a sign extension bug in libc.
> Is there any safe way on x32 to call times(2) directly?

time_t/clock_t/unsigned long long are 64bit in x32.

looks like strace doesn't like it when you call clock_gettime:
strace: syscall_228(...) in unsupported 64-bit mode of process PID=2565

which doesn't make sense as they're the same syscall for x86_64 and x32.
-mike
<1><25>
Abbrev Number: 5 (DW_TAG_base_type)
DW_AT_byte_size   : 1
DW_AT_encoding: 6   (signed char)
DW_AT_name: (indirect string, offset: 0x101): signed char
<1><2c>
Abbrev Number: 5 (DW_TAG_base_type)
DW_AT_byte_size   : 2
DW_AT_encoding: 5   (signed)
DW_AT_name: (indirect string, offset: 0x10d): short int
<1><33>
Abbrev Number: 9 (DW_TAG_base_type)
DW_AT_byte_size   : 4
DW_AT_encoding: 5   (signed)
DW_AT_name: int
<1><3a>
Abbrev Number: 5 (DW_TAG_base_type)
DW_AT_byte_size   : 8
DW_AT_encoding: 5   (signed)
DW_AT_name: (indirect string, offset: 0x0): long long int
<1><41>
Abbrev Number: 5 (DW_TAG_base_type)
DW_AT_byte_size   : 1
DW_AT_encoding: 8  

Re: Preparing for the next release: call for testing

[Mike Frysinger]

i haven't had a chance yet to triage these.

testing commit bab4ef4272cd2596c7390b34ea8acc086ee8fdb2 (v4.10-566-gbab4ef4)

native (build+tests):
vFAIL:  build;  x86_64  ??? linux-4.1.6 kernel-headers-3.4.0   
glibc-2.4   gcc-4.5.4
vFAIL:  test;   armv7l  32-bit/LSB  linux-3.4.0-vapier  kernel-headers-3.18.0  
glibc-2.21  gcc-4.9.3
vFAIL:  test;   x86_64  32-bit/LSB  linux-4.1.6 kernel-headers-4.1.0   
glibc-2.21  gcc-4.9.2
vPASS:  alpha   64-bit/LSB  linux-4.3.0   kernel-headers-4.3.0   
glibc-2.22  gcc-4.9.3
vPASS:  i68632-bit/LSB  linux-4.1.6   kernel-headers-4.0.0   
glibc-2.21  gcc-5.1.0
vPASS:  ia6464-bit/LSB  linux-3.14.14-gentoo  kernel-headers-3.18.0  
glibc-2.20  gcc-4.7.4
vPASS:  parisc  32-bit/MSB  linux-3.18.7-gentoo   kernel-headers-3.18.0  
glibc-2.19  gcc-4.8.4
vPASS:  ppc 32-bit/MSB  linux-3.12.20-gentoo  kernel-headers-4.1.0   
glibc-2.21  gcc-4.8.5
vPASS:  ppc64   64-bit/MSB  linux-3.12.20-gentoo  kernel-headers-3.9.0   
glibc-2.17  gcc-4.8.4
vPASS:  s39032-bit/MSB  linux-4.2.0   kernel-headers-3.18.0  
glibc-2.21  gcc-4.8.5
vPASS:  s390x   64-bit/MSB  linux-4.2.0   kernel-headers-3.18.0  
glibc-2.21  gcc-4.8.5
vPASS:  sparc   32-bit/MSB  linux-3.17.2  kernel-headers-3.18.0  
glibc-2.19  gcc-4.8.4

cross (build only):
vFAIL:  build;  sparc64  ???  cross  kernel-headers-4.3.0  glibc-2.22  gcc-4.6.4
vPASS:  aarch64 64-bit/LSB  cross  kernel-headers-4.3.0  glibc-2.22 
gcc-4.9.2
vPASS:  armv4   32-bit/LSB  cross  kernel-headers-4.3.0  glibc-2.22 
gcc-4.8.0
vPASS:  bfin32-bit/LSB  cross  kernel-headers-3.5.0  uclibc-0.9.33  
gcc-4.5.3
vPASS:  bfin-fdpic  32-bit/LSB  cross  kernel-headers-3.5.0  uclibc-0.9.33  
gcc-4.5.3
vPASS:  m68k32-bit/MSB  cross  kernel-headers-4.3.0  glibc-2.22 
gcc-4.9.2
vPASS:  microblaze  32-bit/MSB  cross  kernel-headers-4.3.0  glibc-2.20 
gcc-4.9.3
vPASS:  mips-n3232-bit/MSB  cross  kernel-headers-4.3.0  glibc-2.22 
gcc-4.7.3
vPASS:  mips-n6464-bit/MSB  cross  kernel-headers-4.3.0  glibc-2.22 
gcc-4.7.3
vPASS:  mips-o3232-bit/MSB  cross  kernel-headers-4.3.0  glibc-2.22 
gcc-4.7.3
vPASS:  tilegx  64-bit/LSB  cross  kernel-headers-4.3.0  glibc-2.22 
gcc-4.8.0
-mike


logs.tar.xz
Description: application/xz


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] printflags: handle empty xlats

[Mike Frysinger]

If the set of headers are unable to produce a valid list, printflags
will try to pass NULL to tprints which crashes.  Add a sanity check
for this edge case.

* util.c (printflags): Check xlat->str is not NULL.
---
 util.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/util.c b/util.c
index c3e3fda..7c19044 100644
--- a/util.c
+++ b/util.c
@@ -353,8 +353,11 @@ printflags(const struct xlat *xlat, int flags, const char 
*dflt)
const char *sep;
 
if (flags == 0 && xlat->val == 0) {
-   tprints(xlat->str);
-   return 1;
+   if (xlat->str) {
+   tprints(xlat->str);
+   return 1;
+   } else
+   return 0;
}
 
sep = "";
-- 
2.5.2


--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] support C libs w/out System V shared memory/ipc

[Mike Frysinger]

Some systems (like Bionic) omit support for SysV related code.  That means
no C library headers for strace to include.  Add configure tests to probe
the headers from the kernel and use them when they're available.

It might make more sense to never rely on the C library's headers as there
is no guarantee or requirement that the structure layout between apps and
the C library match that what is passed to the kernel.

* configure.ac (AC_CHECK_HEADERS): Check for asm/{ipc,msg,sem,shm}buf.h,
linux/ipc.h, linux/mqueue.h, linux/msg.h, linux/sem.h, linux/shm.h, sys/ipc.h,
sys/msg.h, sys/sem.h, and sys/shm.h.
* ipc_defs.h: Include sys/ipc.h and linux/ipc.h depending on what's available.
* ipc_msg.c: Replace ipc/msg headers with ipc_defs.h.
* ipc_msgctl.c: Include sys/msg.h, asm/msgbuf.h, or linux/msg.h based on what's
available.  Note missing support for old ipc structs.
* ipc_sem.c: Include sys/sem.h and linux/sem.h depending on what's available.
Only decode sembuf when available.
* ipc_shm.c: Drop unused sys/shm.h include.
* ipc_shmctl.c: Include sys/shm.h, asm/shmbuf.h, or linux/shm.h based on what's
available.  Note missing support for old ipc structs.
* print_mq_attr.c: Fallback to linux/mqueue.h when available.
---
 configure.ac| 13 +
 ipc_defs.h  |  8 +++-
 ipc_msg.c   |  4 +---
 ipc_msgctl.c| 16 ++--
 ipc_sem.c   | 12 +++-
 ipc_shm.c   |  2 --
 ipc_shmctl.c| 16 +---
 print_mq_attr.c |  3 +++
 8 files changed, 62 insertions(+), 12 deletions(-)

diff --git a/configure.ac b/configure.ac
index 334dd6f..8071f57 100644
--- a/configure.ac
+++ b/configure.ac
@@ -260,6 +260,10 @@ AC_CHECK_FUNCS(m4_normalize([
 ]))
 AC_CHECK_HEADERS(m4_normalize([
asm/cachectl.h
+   asm/ipcbuf.h
+   asm/msgbuf.h
+   asm/sembuf.h
+   asm/shmbuf.h
asm/sysmips.h
bluetooth/bluetooth.h
elf.h
@@ -270,10 +274,15 @@ AC_CHECK_HEADERS(m4_normalize([
linux/filter.h
linux/hiddev.h
linux/ip_vs.h
+   linux/ipc.h
linux/mmtimer.h
+   linux/mqueue.h
+   linux/msg.h
linux/perf_event.h
linux/seccomp.h
linux/securebits.h
+   linux/sem.h
+   linux/shm.h
linux/utsname.h
mqueue.h
netinet/sctp.h
@@ -284,7 +293,11 @@ AC_CHECK_HEADERS(m4_normalize([
sys/eventfd.h
sys/fanotify.h
sys/ioctl.h
+   sys/ipc.h
+   sys/msg.h
sys/reg.h
+   sys/sem.h
+   sys/shm.h
sys/signalfd.h
sys/vfs.h
sys/xattr.h
diff --git a/ipc_defs.h b/ipc_defs.h
index 31f7ab3..3781b95 100644
--- a/ipc_defs.h
+++ b/ipc_defs.h
@@ -25,7 +25,13 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include 
+#ifdef HAVE_SYS_IPC_H
+# include 
+#elif defined(HAVE_LINUX_IPC_H)
+# include 
+/* While glibc uses __key, the kernel uses key. */
+# define __key key
+#endif
 
 #if !defined IPC_64
 # define IPC_64 0x100
diff --git a/ipc_msg.c b/ipc_msg.c
index 55747cb..2fc7470 100644
--- a/ipc_msg.c
+++ b/ipc_msg.c
@@ -31,9 +31,7 @@
  */
 
 #include "defs.h"
-
-#include 
-#include 
+#include "ipc_defs.h"
 
 #include "xlat/ipc_msg_flags.h"
 #include "xlat/resource_flags.h"
diff --git a/ipc_msgctl.c b/ipc_msgctl.c
index a97dd1a..8c83806 100644
--- a/ipc_msgctl.c
+++ b/ipc_msgctl.c
@@ -33,9 +33,20 @@
 #include "defs.h"
 #include "ipc_defs.h"
 
-#include 
-#include DEF_MPERS_TYPE(msqid_ds_t)
+#ifdef HAVE_SYS_MSG_H
+/* The C library generally exports the struct the current kernel expects. */
+# include 
 typedef struct msqid_ds msqid_ds_t;
+#elif defined(HAVE_ASM_MSGBUF_H)
+/* The asm header provides the 64bit struct directly for us. */
+# include 
+typedef struct msqid64_ds msqid_ds_t;
+#elif defined(HAVE_LINUX_MSG_H)
+/* The linux header might provide the right struct. */
+# include 
+typedef struct msqid64_ds msqid_ds_t;
+#endif
+#include DEF_MPERS_TYPE(msqid_ds_t)
 #include MPERS_DEFS
 
 #include "xlat/msgctl_flags.h"
@@ -43,6 +54,7 @@ typedef struct msqid_ds msqid_ds_t;
 static void
 print_msqid_ds(struct tcb *tcp, const long addr, int cmd)
 {
+   /* TODO: We don't properly decode old compat ipc calls. */
if (cmd & IPC_64)
cmd &= ~IPC_64;
msqid_ds_t msqid_ds;
diff --git a/ipc_sem.c b/ipc_sem.c
index e98f8ef..3fd2ded 100644
--- a/ipc_sem.c
+++ b/ipc_sem.c
@@ -33,11 +33,16 @@
 #include "defs.h"
 #include "ipc_defs.h"
 
-#include 
+#ifdef HAVE_SYS_SEM_H
+# include 
+#elif defined(HAVE_LINUX_SEM_H)
+# include 
+#endif
 
 #include "xlat/semctl_flags.h"
 #include "xlat/semop_flags.h"
 
+#if defined(HAVE_SYS_SHM_H) || defined(HAVE_LINUX_SEM_H)
 static void
 tprint_sembuf(const struct sembuf *sb)
 {
@@ -45,10 +50,12 @@ tprint_sembuf(const struct sembuf *sb)
printflags(semop_flags, sb->sem_flg, "SEM_???");
tprints("}");
 }
+#endif
 
 static void
 tprint_sembuf_array(struct tcb *tcp, const long addr, const unsigned long 
count)
 {
+#if 

[PATCH] mpers: fix shell code to conform better to POSIX

[Mike Frysinger]

The `echo -n` behavior is non-portable, so use printf instead.

* generate_mpers_am.sh: Change `echo -n` to `printf`.
---
 generate_mpers_am.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/generate_mpers_am.sh b/generate_mpers_am.sh
index 382ef53..5469c94 100755
--- a/generate_mpers_am.sh
+++ b/generate_mpers_am.sh
@@ -3,7 +3,7 @@
 exec > mpers.am
 
 echo "# Generated by $0; do not edit."
-echo -n 'mpers_source_files = '
+printf 'mpers_source_files = '
 
 sed -n '/^strace_SOURCES[[:space:]]*=/,/^[[:space:]]*# end of strace_SOURCES/ 
s/^[[:space:]]*\([[:alnum:]][^.]*\.c\)[[:space:]]*\\$/\1/p' Makefile.am |
xargs -r grep -lx '#[[:space:]]*include[[:space:]]\+MPERS_DEFS' |
-- 
2.5.2


--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: compile error for MIPS

[Mike Frysinger]

On 26 Aug 2015 13:56, Thomas Schmiedl wrote:
 I have now built strace in a qemu-emulated mips-linux. The call on the 
 real mips-device (router) was:
 
 ./strace -p pid -y -yy -e all -o tracefile
 
 with this output in the tracefile (only the important line):
 
 send(21socket:[38588], \32\0`\200\0\0\20\fKein Bier vor 4\0\0\0, 26, 
 0) = 26
 
 Is it possible to see the commands before and after Kein Bier vor 4, 
 that were transferred between the two processes via an 
 unix-domain-socketfile. I try to send own text to the receiving process, 
 that should send the own text to a connected dect-phone.

what do you mean ?  strace already showed you all the syscalls that the
process made during that time.
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH v4 2/5] drm: Add private data field to trace control block

[Mike Frysinger]

On 24 Aug 2015 14:42, Patrik Jakobsson wrote:
 We need to be able to store private data in the tcb across it's
 lifetime. To ensure proper destruction of the data a free_priv_data
 callback must be provided if an allocation is stored in priv_data. The
 callback is executed automatically when the life of the tcb ends.
 
 * defs.h: Add extern declaration of free_tcb_priv_data.
  (struct tcb): Add priv_data and free_priv_data.
 * strace.c (free_tcb_priv_data): New function
 (drop_tcb): Execute free_tcb_priv_data callback
 * syscall.c (trace_syscall_exiting): Execute free_tcb_priv_data callback
 
 Signed-off-by: Patrik Jakobsson patrik.jakobs...@linux.intel.com
 ---
  defs.h|  6 ++
  strace.c  | 14 ++
  syscall.c |  1 +
  3 files changed, 21 insertions(+)
 
 diff --git a/defs.h b/defs.h
 index 9059026..bc3bd83 100644
 --- a/defs.h
 +++ b/defs.h
 @@ -266,6 +266,10 @@ struct tcb {
   int u_error;/* Error code */
   long scno;  /* System call number */
   long u_arg[MAX_ARGS];   /* System call arguments */
 +
 + void *priv_data;/* Private data for syscall decoding functions 
 */
 + void (*free_priv_data)(void *); /* Callback for freeing priv_data */

should we name these _priv_data and _free_priv_data and provides accessor
functions ?  i worry that code paths might stomp on each other by accident
and we don't end up noticing.

static void set_tcb_priv_data(struct tcb *tcp, void *data, void 
(*free_data)(void *))
{
assert(tcp-_priv_data == NULL  tcp-_free_priv_data == NULL);
...
}
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH/RFC v2] decode extend getsockopt/setsockopt options

[Mike Frysinger]

Currently the code assumes the set of valid options between getsockopt
and setsockopt are exactly the same and thus maintains one list.  The
kernel unfortunately does not do this -- it allows for different opts
between the get and set functions.  See the {g,s}et_opt{min,max} fields
in the various netfilter subcores.

To support this, extend the printxval function to take multiple sets of
xlats as varargs.  Then we add the new get/set lists, and pass them down
in the net code when decoding things.

A simple example is iptables; before:
getsockopt(4, SOL_IP, 0x40 /* IP_??? */, ...) = 0
getsockopt(4, SOL_IP, 0x41 /* IP_??? */, ...) = 0
after:
getsockopt(4, SOL_IP, IPT_SO_GET_INFO, ...) = 0
getsockopt(4, SOL_IP, IPT_SO_GET_ENTRIES, ...) = 0

If these were setsockopt calls, then 0x40  0x41 would be
IPT_SO_SET_REPLACE  IPT_SO_SET_ADD_COUNTERS.

* configure.ac: Check for netfilter headers.
* defs.h (printxvals): New prototype.
(printxval): Change to a define.
* net.c: Include netfilter headers and new sockopts headers.
(print_sockopt_fd_level_name): Add a is_getsockopt argument.  Change SOL_IP
and SOL_IPV6 decoding to use printxvals, and use is_getsockopt to pass more
xlats down.
(getsockopt): Call print_sockopt_fd_level_name with is_getsockopt as true.
(setsockopt): Call print_sockopt_fd_level_name with is_getsockopt as false.
* util.c (printxval): Rename to ...
(printxvals): ... this.  Rewrite to be varargs based.
* xlat/getsockipoptions.in: New xlat list.
* xlat/getsockipv6options.in, xlat/setsockipoptions.in,
xlat/setsockipv6options.in: Likewise.
---
v2
- fix a few typos

 configure.ac   |  8 
 defs.h |  3 ++-
 net.c  | 31 ++-
 util.c | 25 +++--
 xlat/getsockipoptions.in   | 26 ++
 xlat/getsockipv6options.in |  7 +++
 xlat/setsockipoptions.in   | 28 
 xlat/setsockipv6options.in |  5 +
 8 files changed, 121 insertions(+), 12 deletions(-)
 create mode 100644 xlat/getsockipoptions.in
 create mode 100644 xlat/getsockipv6options.in
 create mode 100644 xlat/setsockipoptions.in
 create mode 100644 xlat/setsockipv6options.in

diff --git a/configure.ac b/configure.ac
index fbd20d2..4fedbf5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -261,6 +261,7 @@ AC_CHECK_HEADERS(m4_normalize([
linux/falloc.h
linux/filter.h
linux/hiddev.h
+   linux/ip_vs.h
linux/mmtimer.h
linux/perf_event.h
linux/seccomp.h
@@ -287,6 +288,13 @@ AC_CHECK_HEADERS([linux/icmp.h linux/in6.h linux/netlink.h 
linux/if_packet.h],
 AC_CHECK_HEADERS([asm/sigcontext.h], [], [], [#include signal.h])
 AC_CHECK_TYPES([struct sigcontext],,, [#include signal.h])
 AC_CHECK_HEADERS([netinet/tcp.h netinet/udp.h],,, [#include netinet/in.h])
+AC_CHECK_HEADERS(m4_normalize([
+   linux/netfilter_arp/arp_tables.h
+   linux/netfilter_bridge/ebtables.h
+   linux/netfilter_ipv4/ip_tables.h
+   linux/netfilter_ipv6/ip6_tables.h
+]), [], [], [#include netinet/in.h
+#include net/if.h])
 
 AC_CHECK_TYPES([struct mmsghdr],,, [#include sys/socket.h])
 AC_CHECK_MEMBERS([struct msghdr.msg_control],,, [#include sys/socket.h])
diff --git a/defs.h b/defs.h
index 857175d..9933983 100644
--- a/defs.h
+++ b/defs.h
@@ -516,7 +516,8 @@ extern int printllval(struct tcb *, const char *, int)
ATTRIBUTE_FORMAT((printf, 2, 0));
 
 extern void printaddr(long);
-extern void printxval(const struct xlat *, const unsigned int, const char *);
+extern void printxvals(const unsigned int, const char *, const struct xlat *, 
...);
+#define printxval(xlat, val, dflt) printxvals(val, dflt, xlat, NULL)
 extern int printargs(struct tcb *);
 extern int printargs_lu(struct tcb *);
 extern int printargs_ld(struct tcb *);
diff --git a/net.c b/net.c
index 7e73528..40b5a5c 100644
--- a/net.c
+++ b/net.c
@@ -52,9 +52,24 @@
 # include linux/ipx.h
 #endif
 
+#if defined(HAVE_LINUX_IP_VS_H)
+# include linux/ip_vs.h
+#endif
 #if defined(HAVE_LINUX_NETLINK_H)
 # include linux/netlink.h
 #endif
+#if defined(HAVE_LINUX_NETFILTER_ARP_ARP_TABLES_H)
+# include linux/netfilter_arp/arp_tables.h
+#endif
+#if defined(HAVE_LINUX_NETFILTER_BRIDGE_EBTABLES_H)
+# include linux/netfilter_bridge/ebtables.h
+#endif
+#if defined(HAVE_LINUX_NETFILTER_IPV4_IP_TABLES_H)
+# include linux/netfilter_ipv4/ip_tables.h
+#endif
+#if defined(HAVE_LINUX_NETFILTER_IPV6_IP6_TABLES_H)
+# include linux/netfilter_ipv6/ip6_tables.h
+#endif
 #if defined(HAVE_LINUX_IF_PACKET_H)
 # include linux/if_packet.h
 #endif
@@ -989,7 +1004,11 @@ SYS_FUNC(socketpair)
 
 #include xlat/sockoptions.h
 #include xlat/sockipoptions.h
+#include xlat/getsockipoptions.h
+#include xlat/setsockipoptions.h
 #include xlat/sockipv6options.h
+#include xlat/getsockipv6options.h
+#include xlat/setsockipv6options.h
 #include xlat/sockipxoptions.h
 #include xlat/sockrawoptions.h
 

[PATCH v3] decode extend getsockopt/setsockopt options

[Mike Frysinger]

Currently the code assumes the set of valid options between getsockopt
and setsockopt are exactly the same and thus maintains one list.  The
kernel unfortunately does not do this -- it allows for different opts
between the get and set functions.  See the {g,s}et_opt{min,max} fields
in the various netfilter subcores.

To support this, extend the printxval function to take multiple sets of
xlats as varargs.  Then we add the new get/set lists, and pass them down
in the net code when decoding things.

A simple example is iptables; before:
getsockopt(4, SOL_IP, 0x40 /* IP_??? */, ...) = 0
getsockopt(4, SOL_IP, 0x41 /* IP_??? */, ...) = 0
after:
getsockopt(4, SOL_IP, IPT_SO_GET_INFO, ...) = 0
getsockopt(4, SOL_IP, IPT_SO_GET_ENTRIES, ...) = 0

If these were setsockopt calls, then 0x40  0x41 would be
IPT_SO_SET_REPLACE  IPT_SO_SET_ADD_COUNTERS.

* configure.ac: Check for netfilter headers.
* defs.h (printxvals): New prototype.
(printxval): Change to a define.
* net.c: Include netfilter headers and new sockopts headers.
(print_sockopt_fd_level_name): Add a is_getsockopt argument.  Change SOL_IP
and SOL_IPV6 decoding to use printxvals, and use is_getsockopt to pass more
xlats down.
(getsockopt): Call print_sockopt_fd_level_name with is_getsockopt as true.
(setsockopt): Call print_sockopt_fd_level_name with is_getsockopt as false.
* util.c (printxval): Rename to ...
(printxvals): ... this.  Rewrite to be varargs based.
* xlat/getsockipoptions.in: New xlat list.
* xlat/getsockipv6options.in, xlat/setsockipoptions.in,
xlat/setsockipv6options.in: Likewise.
---
v3
- rework xarargs logic

 configure.ac   |  8 
 defs.h |  3 ++-
 net.c  | 31 ++-
 util.c | 23 +--
 xlat/getsockipoptions.in   | 26 ++
 xlat/getsockipv6options.in |  7 +++
 xlat/setsockipoptions.in   | 28 
 xlat/setsockipv6options.in |  5 +
 8 files changed, 119 insertions(+), 12 deletions(-)
 create mode 100644 xlat/getsockipoptions.in
 create mode 100644 xlat/getsockipv6options.in
 create mode 100644 xlat/setsockipoptions.in
 create mode 100644 xlat/setsockipv6options.in

diff --git a/configure.ac b/configure.ac
index fbd20d2..4fedbf5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -261,6 +261,7 @@ AC_CHECK_HEADERS(m4_normalize([
linux/falloc.h
linux/filter.h
linux/hiddev.h
+   linux/ip_vs.h
linux/mmtimer.h
linux/perf_event.h
linux/seccomp.h
@@ -287,6 +288,13 @@ AC_CHECK_HEADERS([linux/icmp.h linux/in6.h linux/netlink.h 
linux/if_packet.h],
 AC_CHECK_HEADERS([asm/sigcontext.h], [], [], [#include signal.h])
 AC_CHECK_TYPES([struct sigcontext],,, [#include signal.h])
 AC_CHECK_HEADERS([netinet/tcp.h netinet/udp.h],,, [#include netinet/in.h])
+AC_CHECK_HEADERS(m4_normalize([
+   linux/netfilter_arp/arp_tables.h
+   linux/netfilter_bridge/ebtables.h
+   linux/netfilter_ipv4/ip_tables.h
+   linux/netfilter_ipv6/ip6_tables.h
+]), [], [], [#include netinet/in.h
+#include net/if.h])
 
 AC_CHECK_TYPES([struct mmsghdr],,, [#include sys/socket.h])
 AC_CHECK_MEMBERS([struct msghdr.msg_control],,, [#include sys/socket.h])
diff --git a/defs.h b/defs.h
index 857175d..9933983 100644
--- a/defs.h
+++ b/defs.h
@@ -516,7 +516,8 @@ extern int printllval(struct tcb *, const char *, int)
ATTRIBUTE_FORMAT((printf, 2, 0));
 
 extern void printaddr(long);
-extern void printxval(const struct xlat *, const unsigned int, const char *);
+extern void printxvals(const unsigned int, const char *, const struct xlat *, 
...);
+#define printxval(xlat, val, dflt) printxvals(val, dflt, xlat, NULL)
 extern int printargs(struct tcb *);
 extern int printargs_lu(struct tcb *);
 extern int printargs_ld(struct tcb *);
diff --git a/net.c b/net.c
index 7e73528..40b5a5c 100644
--- a/net.c
+++ b/net.c
@@ -52,9 +52,24 @@
 # include linux/ipx.h
 #endif
 
+#if defined(HAVE_LINUX_IP_VS_H)
+# include linux/ip_vs.h
+#endif
 #if defined(HAVE_LINUX_NETLINK_H)
 # include linux/netlink.h
 #endif
+#if defined(HAVE_LINUX_NETFILTER_ARP_ARP_TABLES_H)
+# include linux/netfilter_arp/arp_tables.h
+#endif
+#if defined(HAVE_LINUX_NETFILTER_BRIDGE_EBTABLES_H)
+# include linux/netfilter_bridge/ebtables.h
+#endif
+#if defined(HAVE_LINUX_NETFILTER_IPV4_IP_TABLES_H)
+# include linux/netfilter_ipv4/ip_tables.h
+#endif
+#if defined(HAVE_LINUX_NETFILTER_IPV6_IP6_TABLES_H)
+# include linux/netfilter_ipv6/ip6_tables.h
+#endif
 #if defined(HAVE_LINUX_IF_PACKET_H)
 # include linux/if_packet.h
 #endif
@@ -989,7 +1004,11 @@ SYS_FUNC(socketpair)
 
 #include xlat/sockoptions.h
 #include xlat/sockipoptions.h
+#include xlat/getsockipoptions.h
+#include xlat/setsockipoptions.h
 #include xlat/sockipv6options.h
+#include xlat/getsockipv6options.h
+#include xlat/setsockipv6options.h
 #include xlat/sockipxoptions.h
 #include xlat/sockrawoptions.h
 

Re: [PATCH/RFC] decode extend getsockopt/setsockopt options

[Mike Frysinger]

On 19 Aug 2015 18:56, Dmitry V. Levin wrote:
 On Tue, Aug 18, 2015 at 05:03:20PM -0400, Mike Frysinger wrote:
 [...]
  * util.c (printxval): Rename to ...
  (printxvals): ... this.  Rewrite to be varargs based.
  * xlat/getsockipoptions.in: New xlat list.
  * xlat/getsockipv6options.in, xlat/setsockipoptions.in,
  xlat/setsockipv6options.in: Likewise.
  ---
  RFC: i'm not terribly happy with the printxvals logic.  open to suggestions.
 
 What's it in the printxvals logic that doesn't make you happy?

using varargs all the time when the previous code was just a simple func.
seems like it's adding a good amount of overhead.  maybe i'm pessimistic
as i haven't done any perf checks.

 On Wed, Aug 19, 2015 at 09:14:59AM -0400, Mike Frysinger wrote:
 [...]
  @@ -207,14 +208,26 @@ next_set_bit(const void *bit_array, unsigned cur_bit, 
  unsigned size_bits)
* Print entry in struct xlat table, if there.
*/
   void
  -printxval(const struct xlat *xlat, const unsigned int val, const char 
  *dflt)
  +printxvals(const unsigned int val, const char *dflt, const struct xlat 
  *xlat, ...)
   {
  -   const char *str = xlookup(xlat, val);
  +   va_list args;
  +   const char *str;
  +
  +   va_start(args, xlat);
  +   while (xlat) {
  +   str = xlookup(xlat, val);
  +   if (str) {
  +   tprints(str);
  +   return;
  +   }
   
  -   if (str)
  -   tprints(str);
  -   else
  -   tprintf(%#x /* %s */, val, dflt);
  +   xlat = va_arg(args, const struct xlat *);
  +   if (!xlat) {
  +   tprintf(%#x /* %s */, val, dflt);
  +   break;
  +   }
  +   }
  +   va_end(args);
   }
   
   /*
 
 Wouldn't it be a bit simpler to write it this way:
 
 @@ -207,14 +208,22 @@ next_set_bit(const void *bit_array, unsigned cur_bit, 
 unsigned size_bits)
   * Print entry in struct xlat table, if there.
   */
  void
 -printxval(const struct xlat *xlat, const unsigned int val, const char *dflt)
 +printxvals(const unsigned int val, const char *dflt, const struct xlat 
 *xlat, ...)
  {
 - const char *str = xlookup(xlat, val);
 + va_list args;
  
 - if (str)
 - tprints(str);
 - else
 - tprintf(%#x /* %s */, val, dflt);
 + va_start(args, xlat);
 + for (; xlat; xlat = va_arg(args, const struct xlat *)) {
 + const char *str = xlookup(xlat, val);
 +
 + if (str) {
 + tprints(str);
 + return;
 + }
 + }
 + va_end(args);
 +
 + tprintf(%#x /* %s */, val, dflt);
  }

seems like it'd work too.  although both versions have a bug -- they don't
call va_end before returning.  in my version i could turn it into a break,
but this one needs a 2nd call.  most likely not a big issue.
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

decoding of input/output args ?

[Mike Frysinger]

some syscalls have arguments that are read/write.  for example, getsockopt 
passes in a pointer to a length that has to be set correctly first, and then
the kernel will adjust it when returning.  being able to see both values is
important when getting an error so you can see what the user sent up and what
the kernel sent back.

are there examples in strace to look at ?  perhaps something like:
getsockopt(4, SOL_IP, IPT_SO_GET_ENTRIES, ..., [2900-2804]) = 0
and when you get an error it'd be:
getsockopt(4, SOL_IP, IPT_SO_GET_ENTRIES, 0x12345, [2900-2900]) = EINVAL
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: decoding of input/output args ?

[Mike Frysinger]

On 19 Aug 2015 22:36, Dmitry V. Levin wrote:
 On Wed, Aug 19, 2015 at 03:17:39PM -0400, Mike Frysinger wrote:
  some syscalls have arguments that are read/write.  for example, getsockopt 
  passes in a pointer to a length that has to be set correctly first, and then
  the kernel will adjust it when returning.  being able to see both values is
  important when getting an error so you can see what the user sent up and 
  what
  the kernel sent back.
  
  are there examples in strace to look at ?  perhaps something like:
  getsockopt(4, SOL_IP, IPT_SO_GET_ENTRIES, ..., [2900-2804]) = 0
  and when you get an error it'd be:
  getsockopt(4, SOL_IP, IPT_SO_GET_ENTRIES, 0x12345, [2900-2900]) = EINVAL
 
 I think there is no need to print it in case of an error,
 when it's known to be unchanged.
 
 We have several examples in the code:
 $ git grep '[^a-z] = ' *.c
 mtd.c:tprints( = );
 mtd.c:tprints( = );
 sendfile.c:   tprints( = );
 sendfile.c:   tprints( = );
 sock.c:   tprints( = );
 v4l2.c:   tprints(exiting(tcp)  code != VIDIOC_G_FMT ? 
  =  : , );
 v4l2.c:   tprints(exiting(tcp)  code == VIDIOC_S_PARM ?  = { 
 : , {);
 v4l2.c:   tprints(exiting(tcp) ?  =  : , {id=);
 v4l2.c:   tprints(code != VIDIOC_G_EXT_CTRLS  exiting(tcp) ?  
 =  : , );
 
 The most recent one is from commits v4.10-319-g22f8b27 and
 v4.10-320-g4918285.

output format looks fine.  but there's another wrinkle here :).  sendfile is 
easy -- the leading args are input only, and the last one is input/output,
so incremental output is not an issue.  getsockopt is inputs, then output,
then input/output.  so i can't print the last input in the entering code path
and then print the output in the exiting code path.  i need to read the curr
value, save it in the tcp structure somehow (?), and then read that back out
in the exiting code path.

int getsockopt(int sockfd, int level, int optname,
   void *optval, socklen_t *optlen);

if (entering(tcp)) {
... print sockfd/level/optname ...
tprintf(%i, %i, %i, , tcp-u_arg[0], tcp-u_arg[1], 
tcp-u_arg[2]);
... save current *optlen value ...
umove(tcp, tcp-u_arg[4], tcp-scratch);
} else {
... print optval output ...
print_getsockopt(... tcp-u_arg[3] ...);
... print the *optlen value ...
umove(tcp, tcp-u_arg[4], len);
tprintf([%d], tcp-scratch);
if (tcp-scratch != len)
tprintf( = [%d], len);
}

tips ?
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] signal: SIGSYS: decode si_syscall si_arch fields

[Mike Frysinger]

When receiving SIGSYS, the si_syscall  si_arch fields are set to known
values, so make sure we decode their values into the symbol settings.
This makes stracing seccomp failures much easier.

* defs.h (syscall_name): New prototype.
* printsiginfo.c: Include linux/audit.h and xlat/audit_arch.h.
(print_si_info): Decode si_syscall  si_arch for SIGSYS.
* syscall.c (undefined_scno_name): Delete.
(syscall_name): New function.
(trace_syscall_entering): Change undefined_scno_name to syscall_name.
(trace_syscall_exiting): Likewise.
* xlat/audit_arch.in: New file.
---
 defs.h |  1 +
 printsiginfo.c |  7 +--
 syscall.c  | 18 +++---
 xlat/audit_arch.in | 35 +++
 4 files changed, 52 insertions(+), 9 deletions(-)
 create mode 100644 xlat/audit_arch.in

diff --git a/defs.h b/defs.h
index 74c8d60..29c2131 100644
--- a/defs.h
+++ b/defs.h
@@ -465,6 +465,7 @@ extern void call_summary(FILE *);
 extern void clear_regs(void);
 extern void get_regs(pid_t pid);
 extern int get_scno(struct tcb *tcp);
+extern const char *syscall_name(long scno);
 
 extern int umoven(struct tcb *, long, unsigned int, void *);
 #define umove(pid, addr, objp) \
diff --git a/printsiginfo.c b/printsiginfo.c
index e592854..ce8cf54 100644
--- a/printsiginfo.c
+++ b/printsiginfo.c
@@ -1,9 +1,11 @@
 #include defs.h
 
 #include signal.h
+#include linux/audit.h
 
 #include printsiginfo.h
 
+#include xlat/audit_arch.h
 #include xlat/sigbus_codes.h
 #include xlat/sigchld_codes.h
 #include xlat/sigfpe_codes.h
@@ -154,9 +156,10 @@ print_si_info(const siginfo_t *sip, bool verbose)
break;
 #ifdef HAVE_SIGINFO_T_SI_SYSCALL
case SIGSYS:
-   tprintf(, si_call_addr=%#lx, si_syscall=%d, 
si_arch=%u,
+   tprintf(, si_call_addr=%#lx, si_syscall=__NR_%s, 
si_arch=,
(unsigned long) sip-si_call_addr,
-   sip-si_syscall, sip-si_arch);
+   syscall_name(sip-si_syscall));
+   printxval(audit_arch, sip-si_arch, AUDIT_ARCH_???);
break;
 #endif
default:
diff --git a/syscall.c b/syscall.c
index 6aa1cd2..396a7dd 100644
--- a/syscall.c
+++ b/syscall.c
@@ -745,13 +745,17 @@ shuffle_scno(unsigned long scno)
 # define shuffle_scno(scno) ((long)(scno))
 #endif
 
-static char*
-undefined_scno_name(struct tcb *tcp)
+const char *
+syscall_name(long scno)
 {
static char buf[sizeof(syscall_%lu) + sizeof(long)*3];
 
-   sprintf(buf, syscall_%lu, shuffle_scno(tcp-scno));
-   return buf;
+   if (SCNO_IS_VALID(scno))
+   return sysent[scno].sys_name;
+   else {
+   sprintf(buf, syscall_%lu, shuffle_scno(scno));
+   return buf;
+   }
 }
 
 static long get_regs_error;
@@ -781,7 +785,7 @@ trace_syscall_entering(struct tcb *tcp)
if (scno_good != 1)
tprints( /* anti-trigraph gap */ ();
else if (tcp-qual_flg  UNDEFINED_SCNO)
-   tprintf(%s(, undefined_scno_name(tcp));
+   tprintf(%s(, syscall_name(tcp-scno));
else
tprintf(%s(, tcp-s_ent-sys_name);
/*
@@ -843,7 +847,7 @@ trace_syscall_entering(struct tcb *tcp)
 
printleader(tcp);
if (tcp-qual_flg  UNDEFINED_SCNO)
-   tprintf(%s(, undefined_scno_name(tcp));
+   tprintf(%s(, syscall_name(tcp-scno));
else
tprintf(%s(, tcp-s_ent-sys_name);
if ((tcp-qual_flg  QUAL_RAW)  SEN_exit != tcp-s_ent-sen)
@@ -907,7 +911,7 @@ trace_syscall_exiting(struct tcb *tcp)
tcp-flags = ~TCB_REPRINT;
printleader(tcp);
if (tcp-qual_flg  UNDEFINED_SCNO)
-   tprintf(... %s resumed , undefined_scno_name(tcp));
+   tprintf(... %s resumed , syscall_name(tcp-scno));
else
tprintf(... %s resumed , tcp-s_ent-sys_name);
}
diff --git a/xlat/audit_arch.in b/xlat/audit_arch.in
new file mode 100644
index 000..aa9ccdb
--- /dev/null
+++ b/xlat/audit_arch.in
@@ -0,0 +1,35 @@
+AUDIT_ARCH_AARCH64
+AUDIT_ARCH_ALPHA
+AUDIT_ARCH_ARM
+AUDIT_ARCH_ARMEB
+AUDIT_ARCH_CRIS
+AUDIT_ARCH_FRV
+AUDIT_ARCH_I386
+AUDIT_ARCH_IA64
+AUDIT_ARCH_M32R
+AUDIT_ARCH_M68K
+/* Linux had broken linux/elf-em.h for a while.  */
+#ifdef EM_MICROBLAZE
+AUDIT_ARCH_MICROBLAZE
+#endif
+AUDIT_ARCH_MIPS
+AUDIT_ARCH_MIPS64
+AUDIT_ARCH_MIPS64N32
+AUDIT_ARCH_MIPSEL
+AUDIT_ARCH_MIPSEL64
+AUDIT_ARCH_MIPSEL64N32
+AUDIT_ARCH_OPENRISC
+AUDIT_ARCH_PARISC
+AUDIT_ARCH_PARISC64
+AUDIT_ARCH_PPC
+AUDIT_ARCH_PPC64
+AUDIT_ARCH_PPC64LE
+AUDIT_ARCH_S390
+AUDIT_ARCH_S390X
+AUDIT_ARCH_SH
+AUDIT_ARCH_SH64
+AUDIT_ARCH_SHEL
+AUDIT_ARCH_SHEL64
+AUDIT_ARCH_SPARC
+AUDIT_ARCH_SPARC64
+AUDIT_ARCH_X86_64
-- 
2.4.4

[PATCH/RFC] decode extend getsockopt/setsockopt options

[Mike Frysinger]

Currently the code assumes the set of valid options between getsockopt
and setsockopt are exactly the same and thus maintain one list.  The
kernel unfortunately does not do this -- it allows for different opts
between the get and set functions.  See the {g,s}et_opt{min,max} fields
in the various netfilter subcores.

To support this, extend the printxval function to take multiple sets of
xlats as varargs.  Then we add the new get/set lists, and pass them down
in the net code when decoding things.

A simple example is iptables:
getsockopt(4, SOL_IP, 0x40 /* IP_??? */, ...) = 0
getsockopt(4, SOL_IP, 0x41 /* IP_??? */, ...) = 0
getsockopt(4, SOL_IP, IPT_SO_GET_INFO, ...) = 0
getsockopt(4, SOL_IP, IPT_SO_GET_ENTRIES, ...) = 0

If these were setsockopt, then 0x40  0x41 would be IPT_SO_SET_REPLACE
 IPT_SO_SET_ADD_COUNTERS.

* configure.ac: Check for netfilter headers.
* defs.h (printxvals): New prototype.
(printxval): Change to a define.
* net.c: Include netfilter headers and new sockopts headers.
(print_sockopt_fd_level_name): Add a is_getsockopt argument.  Change SOL_IP
and SOL_IPV6 decoding to use printxvals, and use is_getsockopt to pass more
xlats down.
(getsockopt): Call print_sockopt_fd_level_name with is_getsockopt as true.
(setsockopt): Call print_sockopt_fd_level_name with is_getsockopt as false.
* util.c (printxval): Rename to ...
(printxvals): ... this.  Rewrite to be varargs based.
* xlat/getsockipoptions.in: New xlat list.
* xlat/getsockipv6options.in, xlat/setsockipoptions.in,
xlat/setsockipv6options.in: Likewise.
---
RFC: i'm not terribly happy with the printxvals logic.  open to suggestions.

 configure.ac   |  8 
 defs.h |  3 ++-
 net.c  | 28 +++-
 util.c | 25 +++--
 xlat/getsockipoptions.in   | 26 ++
 xlat/getsockipv6options.in |  7 +++
 xlat/setsockipoptions.in   | 28 
 xlat/setsockipv6options.in |  5 +
 8 files changed, 118 insertions(+), 12 deletions(-)
 create mode 100644 xlat/getsockipoptions.in
 create mode 100644 xlat/getsockipv6options.in
 create mode 100644 xlat/setsockipoptions.in
 create mode 100644 xlat/setsockipv6options.in

diff --git a/configure.ac b/configure.ac
index fbd20d2..4fedbf5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -261,6 +261,7 @@ AC_CHECK_HEADERS(m4_normalize([
linux/falloc.h
linux/filter.h
linux/hiddev.h
+   linux/ip_vs.h
linux/mmtimer.h
linux/perf_event.h
linux/seccomp.h
@@ -287,6 +288,13 @@ AC_CHECK_HEADERS([linux/icmp.h linux/in6.h linux/netlink.h 
linux/if_packet.h],
 AC_CHECK_HEADERS([asm/sigcontext.h], [], [], [#include signal.h])
 AC_CHECK_TYPES([struct sigcontext],,, [#include signal.h])
 AC_CHECK_HEADERS([netinet/tcp.h netinet/udp.h],,, [#include netinet/in.h])
+AC_CHECK_HEADERS(m4_normalize([
+   linux/netfilter_arp/arp_tables.h
+   linux/netfilter_bridge/ebtables.h
+   linux/netfilter_ipv4/ip_tables.h
+   linux/netfilter_ipv6/ip6_tables.h
+]), [], [], [#include netinet/in.h
+#include net/if.h])
 
 AC_CHECK_TYPES([struct mmsghdr],,, [#include sys/socket.h])
 AC_CHECK_MEMBERS([struct msghdr.msg_control],,, [#include sys/socket.h])
diff --git a/defs.h b/defs.h
index 857175d..9933983 100644
--- a/defs.h
+++ b/defs.h
@@ -516,7 +516,8 @@ extern int printllval(struct tcb *, const char *, int)
ATTRIBUTE_FORMAT((printf, 2, 0));
 
 extern void printaddr(long);
-extern void printxval(const struct xlat *, const unsigned int, const char *);
+extern void printxvals(const unsigned int, const char *, const struct xlat *, 
...);
+#define printxval(xlat, val, dflt) printxvals(val, dflt, xlat, NULL)
 extern int printargs(struct tcb *);
 extern int printargs_lu(struct tcb *);
 extern int printargs_ld(struct tcb *);
diff --git a/net.c b/net.c
index 7e73528..8a0c8f2 100644
--- a/net.c
+++ b/net.c
@@ -55,6 +55,18 @@
 #if defined(HAVE_LINUX_NETLINK_H)
 # include linux/netlink.h
 #endif
+#if defined(HAVE_LINUX_NETFILTER_ARP_ARP_TABLES_H)
+# include linux/netfilter_arp/arp_tables.h
+#endif
+#if defined(HAVE_LINUX_NETFILTER_BRIDGE_EBTABLES_H)
+# include linux/netfilter_bridge/ebtables.h
+#endif
+#if defined(HAVE_LINUX_NETFILTER_IPV4_IP_TABLES_H)
+# include linux/netfilter_ipv4/ip_tables.h
+#endif
+#if defined(HAVE_LINUX_NETFILTER_IPV6_IP6_TABLES_H)
+# include linux/netfilter_ipv6/ip6_tables.h
+#endif
 #if defined(HAVE_LINUX_IF_PACKET_H)
 # include linux/if_packet.h
 #endif
@@ -989,7 +1001,11 @@ SYS_FUNC(socketpair)
 
 #include xlat/sockoptions.h
 #include xlat/sockipoptions.h
+#include xlat/getsockipoptions.h
+#include xlat/setsockipoptions.h
 #include xlat/sockipv6options.h
+#include xlat/getsockipv6options.h
+#include xlat/setsockipv6options.h
 #include xlat/sockipxoptions.h
 #include xlat/sockrawoptions.h
 #include xlat/sockpacketoptions.h
@@ -997,7 +1013,7 @@ SYS_FUNC(socketpair)
 #include xlat/socktcpoptions.h
 
 

Re: [PATCH] device mapper support for strace

[Mike Frysinger]

On 11 Aug 2015 13:11, Mikulas Patocka wrote:
 --- /dev/null
 +++ strace/dm.c
 @@ -0,0 +1,354 @@
 +#include defs.h

all files should have a comment block at the top.  see mtd.c as an example.

 +{
 + switch (code) {
 + case DM_REMOVE_ALL:

case statements should be at the same indent level as the switch.  see mtd.c.

 + size_t offset = ioc-data_start;

data_start is a __u32, so this should be uint32_t instead of size_t

 + tprintf(, {sector_start=%llu, length=%llu,
 + (unsigned long long)s-sector_start,
 + (unsigned long long)s-length);

sector_start/length are uint64_t, not unsigned long long.  please use PRIu64 
defines from inttypes.h instead of random casts.  you can find plenty of 
examples in the tree already.

 + if (!entering(tcp))
 + tprintf(, status=%d, (int)s-status);

status is int32_t, not int, so please use PRId32 instead of int casts.

 +static void
 +dm_decode_dm_target_deps(const struct dm_ioctl *ioc, const char *extra,
 +  size_t extra_size)
 +{
 + size_t offset = ioc-data_start;

uint32_t, not size_t

 + if (offset + offsetof(struct dm_target_deps, dev) = offset 
 + offset + offsetof(struct dm_target_deps, dev) = extra_size) {
 + uint32_t i;
 + size_t space = (extra_size - (offset +
 + offsetof(struct dm_target_deps, dev))) / sizeof(__u64);
 + const struct dm_target_deps *s =
 + (const struct dm_target_deps *)(extra + offset);
 + if (s-count  space)
 + goto misplaced;

count is __u32, so space should probably be uint32_t instead of size_t

 +misplaced:

it's not standard in strace, but personal preference is to put a
single space before labels to help out with diff context

 + size_t offset = ioc-data_start;

uint32_t

 +misplaced:

add a space

looks like many of these comments apply to the rest of this file,
so i'll refrain from repeating myself
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH v3 1/5] drm: Add config for detecting libdrm

[Mike Frysinger]

On 30 Jul 2015 15:30, Patrik Jakobsson wrote:
 On Thu, Jul 23, 2015 at 05:48:21AM -0400, Mike Frysinger wrote:
  On 01 Jul 2015 14:52, Patrik Jakobsson wrote:
   Use pkg-config to try to find libdrm. If that fails use the standard
   include directory for kernel drm headers in /usr/include/drm.
   
   * configure.ac: Use pkg-config to find libdrm
   
   Signed-off-by: Patrik Jakobsson patrik.jakobs...@linux.intel.com
   ---
configure.ac | 4 
1 file changed, 4 insertions(+)
   
   diff --git a/configure.ac b/configure.ac
   index bb8bf46..aa63af7 100644
   --- a/configure.ac
   +++ b/configure.ac
   @@ -844,6 +844,10 @@ fi
AM_CONDITIONAL([USE_LIBUNWIND], [test x$use_libunwind = xyes])
AC_MSG_RESULT([$use_libunwind])

   +PKG_CHECK_MODULES([libdrm], [libdrm],
   + [CPPFLAGS=$CPPFLAGS $libdrm_CFLAGS],
   + [CPPFLAGS=$CPPFLAGS -I/usr/include/drm])
  
  yikes, no, this is a really really bad idea.  it should read:
  PKG_CHECK_MODULES([LIBDRM], [libdrm],
  [CPPFLAGS=$CPPFLAGS $LIBDRM_CFLAGS], [:])
 
 I take it you don't want me to fallback on kernel headers and skip
 compiling with drm support if libdrm is not available?

you cannot hardcode any path at all.  if the kernel headers provide all
of the defines/structs that you need, then just include them directly
via #include drm/xxx.h.
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH v3 1/5] drm: Add config for detecting libdrm

[Mike Frysinger]

On 23 Jul 2015 13:44, Dmitry V. Levin wrote:
 On Thu, Jul 23, 2015 at 05:48:21AM -0400, Mike Frysinger wrote:
  On 01 Jul 2015 14:52, Patrik Jakobsson wrote:
   Use pkg-config to try to find libdrm. If that fails use the standard
   include directory for kernel drm headers in /usr/include/drm.
   
   * configure.ac: Use pkg-config to find libdrm
   
   Signed-off-by: Patrik Jakobsson patrik.jakobs...@linux.intel.com
   ---
configure.ac | 4 
1 file changed, 4 insertions(+)
   
   diff --git a/configure.ac b/configure.ac
   index bb8bf46..aa63af7 100644
   --- a/configure.ac
   +++ b/configure.ac
   @@ -844,6 +844,10 @@ fi
AM_CONDITIONAL([USE_LIBUNWIND], [test x$use_libunwind = xyes])
AC_MSG_RESULT([$use_libunwind])

   +PKG_CHECK_MODULES([libdrm], [libdrm],
   + [CPPFLAGS=$CPPFLAGS $libdrm_CFLAGS],
   + [CPPFLAGS=$CPPFLAGS -I/usr/include/drm])
  
  yikes, no, this is a really really bad idea.  it should read:
  PKG_CHECK_MODULES([LIBDRM], [libdrm],
  [CPPFLAGS=$CPPFLAGS $LIBDRM_CFLAGS], [:])
 
 Why [:] ?  Wouldn't [] suffice?

probably ... force of habit after being bitten by m4 macros that did not expect
to expand empty code and thus lead to shell errors (include macros by autotools
projects).  i.e. if the m4 looked something like:
if ...check if pkg is available...; then
$3
else
$4
fi
then the generated configure script would have syntax errors.
-mike


signature.asc
Description: Digital signature
--
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH] Add support for Altera's Nios-II softcore architecture

[Mike Frysinger]

On 19 Apr 2015 15:36, Ezequiel Garcia wrote:
 Hm... I have a very limited test platform here.
 
 Can only boot limited size initramfs. I could try to fix my bootloader
 to allow bigger initramfs, but this might take a lot of time.
 
 Am I required to run 'make check' to merge this?
 
 (Or maybe someone with NFSroot can give it a shot)

are there any useful hardware platforms / qemu builds out there ?  a limited 
FPGA board is ... boring ;).
-mike


signature.asc
Description: Digital signature
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: bugfix for strace for less-aligned kernel memory

[Mike Frysinger]

On 09 Apr 2015 15:23, Bolo wrote:
  can you post them as sep patches please.  and use the unified diff format ?
  no one uses the context format anymore because no one can actually read it.
 
 I'll be happy to do that.
 
 You may not use context diffs, but they are still wide use.

nowhere that matters in the open source world
-mike


signature.asc
Description: Digital signature
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Fix for building against musl

[Mike Frysinger]

Acked-by: Mike Frysinger vap...@gentoo.org
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH] printstatfs missing f_flags

[Mike Frysinger]

On 17 Mar 2015 16:00, enh wrote:
 Show f_flags field in printstatfs
 
 printstatfs64 was right, but printstatfs was missing f_flags.
 Noticed on aarch64.
 
 Signed-off-by: Elliott Hughes e...@google.com

what i meant was this part:
* statfs.c (printstatfs) [_STATFS_F_FLAGS]: Print statfs.f_flags.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH v2] Fix crash in ipc_sem test

[Mike Frysinger]

On 17 Mar 2015 09:20, Andreas Schwab wrote:
 Mike Frysinger vapier-abrp7r+bbdudnm+yrof...@public.gmane.org writes:
  the kernel is still broken,
 
 In which way?

with the older ipc_sem (before 4ed340bae64c84897fa7e42f6142592ef899f0cd), 
building that ipc_sem and running strace on it creates an unkillable proc.

with a 64bit kernel:
$ uname -a
Linux timberdoodle 3.12.20-gentoo #1 SMP Wed May 28 07:47:29 PDT 2014 ppc64 
POWER7 (architected) CHRP IBM,8231-E2B GNU/Linux

build that ipc_sem.c as a 32bit ppc prog.  then run it like so:
$ setarch ppc -XBIST3LZR strace ./ipc_sem
stuck forever  kill -9 doesn't help
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH] Introduce xmalloc, memory allocator with die_out_of_memory()

[Mike Frysinger]

On 20 Mar 2015 13:30, Dmitry V. Levin wrote:
 On Fri, Mar 20, 2015 at 02:53:39PM +0900, Masatake YAMATO wrote:
  In strace following code sentences are frequently used:
  
 var = malloc(fdsize);
  if (!var)
 die_out_of_memory();
  
  This patch introduces xmalloc and friends which simplify
  above sentences like:
  
 var = xmalloc(fdsize);
  
  Here friends are xcalloc and xrealloc.
 
 Do we need xrealloc in its classic form, or rather an edition
 with an integer overflow check?

a xcalloc variant that doesn't clear memory would be nice (and checks the 
multiplication), although i think we can merge this one as-is and build on
top of it.  is there a standard naming for the array allocator ?
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH 2/3] Print the hit rate of socket address cache with -C option

[Mike Frysinger]

On 20 Mar 2015 01:17, Masatake YAMATO wrote:
 --- a/socketutils.c
 +++ b/socketutils.c

 +void
 +sockaddr_cache_summary(FILE * outf)

no space after the *
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH 1/3] Introduce socket address information caching(scache) layer

[Mike Frysinger]

On 20 Mar 2015 01:17, Masatake YAMATO wrote:
 --- a/socketutils.c
 +++ b/socketutils.c
 @@ -7,6 +7,7 @@
  #include linux/inet_diag.h
  #include linux/unix_diag.h
  #include linux/rtnetlink.h
 +#include assert.h

shouldn't all non-linux/asm headers be before linux/asm includes ?

 +#define ENTRY(e) ((struct scache_entry*)(e))

prob want a space before the *

 +struct scache_protocol {
 + const char *name;/* Must */
 + size_t size; /* Must */
 + void (* print) (struct scache_entry *entry); /* Must */

no space before the (

 +static struct scache_entry *
 +scache_entry_init(struct scache_entry *entry,
 +   unsigned long inode,
 +   struct scache_protocol *protocol)
 +{
 + memset(entry, 0, protocol-size);
 + entry-inode = inode;
 + entry-protocol = protocol;
 + return entry;
 +}
 +
 +static void
 +scach_entry_free(struct scache_entry *entry)

typo -- scache

 +{
 + free (entry);
 +}

no space before the (

 +/* Hashtable keyed by inode number */

periods at the end of sentences

 +#define SCACHE_ENTRIES_SIZE 43
 +static struct scache_entry *scache_entries [SCACHE_ENTRIES_SIZE];

no space before the [

 +/* Least Recenly Used queue
 + * If strace records all established sockets, the cache will overflow.
 + * With this LRU queue, unused sockets can be thrown away.
 + */

would trying to have a general hash map/lru queue/linked list be worth the code 
overhead ?  glib and such seems to pull it off.  seems crazy  error prone to 
have to implement these inline everytime we want these datastructures ...

 + if ((*chain) == entry) {

no need for those inner parens

 + e = malloc(s);
 + if (!e)
 + die_out_of_memory();

not a new issue, but we probably could do with a xmalloc helper

 + return r? true: false;

space before the r, or just return !!r

 --- a/util.c
 +++ b/util.c
  
 +static bool
 +printsockinode(struct tcb *tcp, int fd, unsigned long inodenr)
 +{
 + if (print_sockaddr_in_cache(inodenr))
 + return true;
 + else {
 +#define PROTO_NAME_LEN 32
 + char proto_buf[PROTO_NAME_LEN];
 + const char *proto;
 +
 + proto = getfdproto(tcp, fd, proto_buf, PROTO_NAME_LEN);

seems like you just use sizeof() and drop PROTO_NAME_LEN
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH 3/3] Adapt TCP and TCPv6 to the socket address caching layer

[Mike Frysinger]

On 20 Mar 2015 01:17, Masatake YAMATO wrote:
 + struct inet4_entry *entry4 = (struct inet4_entry *)entry;

seems like the scache logic should have helpers for this

 +static struct scache_protocol udp_protocol = {
 +static struct scache_protocol tcp_protocol = {
 +static struct scache_protocol udpv6_protocol = {
 +static struct scache_protocol tcpv6_protocol = {

mark these const

 + scache_entries_add (entry);

no space before the (
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: bugfix for strace for less-aligned kernel memory

[Mike Frysinger]

On 19 Mar 2015 15:48, Bolo wrote:
 This bugfix / patch consists of two portions

can you post them as sep patches please.  and use the unified diff format ?
no one uses the context format anymore because no one can actually read it.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Fix for building against musl

[Mike Frysinger]

On 16 Mar 2015 21:42, Felix Janda wrote:
 asm/ioctl.h is for example needed for _IOC_SIZE(). That is
 likely also the reason why ioctl.c includes it.

we should stick to linux/ioctl.h imo, and update ioctl.c to match
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH v2] Fix crash in ipc_sem test

[Mike Frysinger]

fwiw, 68804b326709fadc7bb03f510a11771f07216a59 passes on ppc32  sparc32 
userland where they were crashing/hanging before

the kernel is still broken, but at least the strace tests don't hit that :)
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH] printstatfs missing f_flags

[Mike Frysinger]

can you include changelog entries in the messages ?
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Fix for building against musl

[Mike Frysinger]

On 17 Mar 2015 15:18, Dmitry V. Levin wrote:
 On Tue, Mar 17, 2015 at 03:36:55AM -0400, Mike Frysinger wrote:
  On 16 Mar 2015 21:42, Felix Janda wrote:
   asm/ioctl.h is for example needed for _IOC_SIZE(). That is
   likely also the reason why ioctl.c includes it.
 
 evdev.c includes linux/input.h which includes sys/ioctl.h.
 On glibc, this leads to inclusion of asm/ioctl.h, musl may do things
 differently.
 
  we should stick to linux/ioctl.h imo, and update ioctl.c to match
 
 I'm OK with including asm/ioctl.h; linux/ioctl.h includes other
 headers besides asm/ioctl.h.

i think generally we should be sticking to linux/xxx.h unless we specifically 
need something out of asm/xxx.h.  although i'm not sure what you mean in this 
case ...

$ cat include/uapi/linux/ioctl.h 
#ifndef _LINUX_IOCTL_H
#define _LINUX_IOCTL_H

#include asm/ioctl.h

#endif /* _LINUX_IOCTL_H */
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH] m68k: fix sigreturn decoding

[Mike Frysinger]

On 11 Mar 2015 15:10, Andreas Schwab wrote:
 + addr -= sizeof (mask) - sizeof(long);
 + if (umoven(tcp, addr, sizeof (mask) - sizeof(long), (char *) 
 mask[1])  0)

should be consistent with sizeof (foo) vs sizeof(foo) (should use the latter)
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: ./bootstrap failing

[Mike Frysinger]

On 06 Mar 2015 15:14, Christopher Covington wrote:
 On 03/06/2015 02:43 PM, Mike Frysinger wrote:
  On 06 Mar 2015 13:29, Christopher Covington wrote:
  I want this behavior so that from a simple shell script I can build the 
  latest
  git checkout of strace, starting from the very beginning, in a directory 
  that
  may have a previous build present. If anyone has suggestions of a better 
  way
  to do this, please let me know.
  
  if you care about this, then build out of tree:
   d=build/$(date +%s)
   mkdir -p $d
   cd $d
   ../../configure ...
 
 Thanks for the response. Just to be clear, you're suggesting running
 ./bootstrap in-tree and then configure, and subsequent steps out-of-tree?

yes

 been making a copy of the source into a working directory and doing an in-tree
 build in the working directory in order to keep the source directory pristine,
 but I'm having trouble remembering a real reason for the pristine source
 directory now that I think about it. Maybe it was that my default git commands
 might fail given conflicts, but I can change them to be more forceful.

`git clean -x -d -f` will delete everything that git doesn't know about

`git checkout -f` will check out all files that git knows about to their 
normal state
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: ./bootstrap failing

[Mike Frysinger]

On 06 Mar 2015 13:29, Christopher Covington wrote:
 On 03/04/2015 10:16 AM, Dmitry V. Levin wrote:
  On Wed, Mar 04, 2015 at 08:48:11AM -0500, Christopher Covington wrote:
  I'm getting the following error:
 
  ./bootstrap
  ln: failed to create symbolic link `tests-m32/Makefile': File exists
  
  Thanks, fixed.
  
  Should the operation perhaps be forced or only performed if a link doesn't
  already exist?
  
  A forced linking may lead to overwriting build results.
  Why anyone might want this behavior?
 
 Re-running make may lead to overwriting build results. Re-running configure
 may lead to overwriting build results. Re-running autoreconf may lead to
 overwriting build results. Re-running xlat/gen.sh may lead to overwriting
 build results. Following this trend, I expect, and I would guess that many
 others would expect, that re-running bootstrap may lead to overwriting build
 results.
 
 I want this behavior so that from a simple shell script I can build the latest
 git checkout of strace, starting from the very beginning, in a directory that
 may have a previous build present. If anyone has suggestions of a better way
 to do this, please let me know.

if you care about this, then build out of tree:
 d=build/$(date +%s)
 mkdir -p $d
 cd $d
 ../../configure ...

i don't think bootstrap should concern itself with preserving generated files
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 05 Mar 2015 09:03, Dmitry V. Levin wrote:
 On Wed, Mar 04, 2015 at 10:55:45PM -0500, Mike Frysinger wrote:
  testing commit a1c5e0721fb679a550ac0cd2c9e231409ebb1e26 (v4.9-391-ga1c5e07)
  
  native (build+tests):
  vFAIL:  test;  parisc  32-bit/MSB  linux-3.16.2-gentoo  
  kernel-headers-3.16.0  glibc-2.19  gcc-4.7.3
 
 This is the architecture where SIGRTMIN has been changed from 37 to 32
 recently.  I've made the test a bit more flexible.

i haven't fully updated the system there yet.  probably should do that soon :).
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

testing commit a1c5e0721fb679a550ac0cd2c9e231409ebb1e26 (v4.9-391-ga1c5e07)

native (build+tests):
vFAIL:  test;  parisc  32-bit/MSB  linux-3.16.2-gentoo  kernel-headers-3.16.0  
glibc-2.19  gcc-4.7.3
vFAIL:  test;  s390x   64-bit/MSB  linux-3.19.0 kernel-headers-3.16.0  
glibc-2.19  gcc-4.8.3
vPASS:  alpha   64-bit/LSB  linux-3.18.1  kernel-headers-3.19.0  
glibc-2.20  gcc-4.9.2
vPASS:  armv7l  32-bit/LSB  linux-3.4.0-vapierkernel-headers-3.16.0  
glibc-2.19  gcc-4.7.3
vPASS:  i68632-bit/LSB  linux-3.19.0  kernel-headers-3.3.0   
glibc-2.17  gcc-4.7.2
vPASS:  ia6464-bit/LSB  linux-3.14.14-gentoo  kernel-headers-3.16.0  
glibc-2.19  gcc-4.7.4
vPASS:  ppc 32-bit/MSB  linux-3.12.20-gentoo  kernel-headers-3.13.0  
glibc-2.21  gcc-4.8.4
vPASS:  ppc64   64-bit/MSB  linux-3.12.20-gentoo  kernel-headers-3.9.0   
glibc-2.17  gcc-4.7.3
vPASS:  s39032-bit/MSB  linux-3.19.0  kernel-headers-3.16.0  
glibc-2.19  gcc-4.8.3
vPASS:  sh4 32-bit/LSB  linux-2.6.30.9kernel-headers-3.13.0  
glibc-2.17  gcc-4.7.3
vPASS:  sparc   32-bit/MSB  linux-3.17.2  kernel-headers-3.13.0  
glibc-2.19  gcc-4.7.3
vPASS:  x86_64  32-bit/LSB  linux-3.19.0  kernel-headers-3.19.0  
glibc-2.21  gcc-4.9.2
vPASS:  x86_64  64-bit/LSB  linux-3.19.0  kernel-headers-3.4.0   
glibc-2.4   gcc-4.5.4

cross (build only):
vPASS:  aarch64 64-bit/LSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.8.2
vPASS:  armv4   32-bit/LSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.8.0
vPASS:  bfin32-bit/LSB  cross  kernel-headers-3.5.0   uclibc-0.9.33  
gcc-4.5.3
vPASS:  bfin-fdpic  32-bit/LSB  cross  kernel-headers-3.5.0   uclibc-0.9.33  
gcc-4.5.3
vPASS:  m68k32-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.8.0
vPASS:  microblaze  32-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.20 
gcc-4.9.2
vPASS:  mips-n3232-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.6.4
vPASS:  mips-n6464-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.6.4
vPASS:  mips-o3232-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.6.4
vPASS:  sparc64 64-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.6.4
vPASS:  tilegx  64-bit/LSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.8.0

build warnings:
signal.c:702:45: warning: signed and unsigned type in conditional expression 
[-Wsign-compare]
syscall.c:746:34: warning: initialization from incompatible pointer type 
[enabled by default]


logs.tar.xz
Description: application/xz


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 04 Mar 2015 22:55, Mike Frysinger wrote:
 build warnings:

also warning on ppc64:
signal.c:802:9: warning: array subscript is above array bounds [-Warray-bounds]
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 03 Mar 2015 21:46, Dmitry V. Levin wrote:
 On Tue, Mar 03, 2015 at 01:23:53PM -0500, Mike Frysinger wrote:
  On 03 Mar 2015 21:01, Dmitry V. Levin wrote:
   On Tue, Mar 03, 2015 at 12:47:19PM -0500, Mike Frysinger wrote:
build warnings:
there's still random -Wsign-compare warnings, but i guess we don't care
about those
   
   There are exactly 3 different -Wsign-compare warning messages:
   socketutils.c:145: warning: comparison between signed and unsigned 
   integer expressions [-Wsign-compare]
   netlink_inet_diag.c:67: warning: comparison between signed and unsigned 
   integer expressions [-Wsign-compare]
   netlink_unix_diag.c:75: warning: comparison between signed and unsigned 
   integer expressions [-Wsign-compare]
   
   The only way to fix them is to fix NLMSG_OK macro defined
   in linux/netlink.h.
  
  hmm, i'm not so sure.  the kernel headers declare:
  struct nlmsghdr {
  __u32   nlmsg_len;  /* Length of message including header */
  ...
  #define NLMSG_OK(nlh,len) ((len) = (int)sizeof(struct nlmsghdr)  \
 (nlh)-nlmsg_len = sizeof(struct nlmsghdr)  \
 (nlh)-nlmsg_len = (len))
  
  and the strace code does:
  ssize_t ret;
  struct nlmsghdr *h;
  ...
   NLMSG_OK(h, ret);
  
  if the kernel headers provided a function instead of a macro, it'd be:
  static bool NLMSG_OK(const struct nlmsghdr *nlh, __u32 len) {...}
  
  which is to say, the API of this macro is that it takes a u32 len, but 
  we're 
  passing it a ssize_t (as that is what recvmsg/etc... returns).  it is 
  annoying 
  that there's a type mismatch here, but i think the problem is still on our 
  side 
  to sort out:
  NLMSG_OK(h, (size_t)ret)
 
 If we pass (size_t)ret to NLMSG_OK, it would result to
   ((size_t)ret) = (int)sizeof(struct nlmsghdr)
 and this code generates the same -Wsign-compare warning.
 I actually tried it some time ago.

blah lame.  i'll try sending a patch upstream and see what they say.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: trouble in kernel header inclusion in ./ioctls_gen.sh

[Mike Frysinger]

On 04 Mar 2015 06:40, Masatake YAMATO wrote:
 When I run ioctls_gen.sh by hand, I got some errors:
 
 $ ./ioctls_gen.sh ~/var/linux/include ~/var/linux/arch/x86/include
 ...
 /home/yamato/var/linux/include/uapi/linux/am437x-vpfe.h:122:12: error: 
 ‘BASE_VIDIOC_PRIVATE’ undeclared (first use in this function)
   _IOW('V', BASE_VIDIOC_PRIVATE + 1, void *)
   ^
 /tmp/ioctls_sym.sh.DPfTZI/asm/ioctl.h:3:43: note: in definition of macro 
 ‘_IOC’
  #define _IOC(dir,type,nr,size) dir, type, nr, size
 ...
 
 BASE_VIDIOC_PRIVATE is defined in linux/videodev2.h.
 
 With a following patch, ioctls_gen.sh works well without above error.
 
 diff --git a/include/uapi/linux/am437x-vpfe.h 
 b/include/uapi/linux/am437x-vpfe.h
 index 9b03033f..c28b4e4 100644
 --- a/include/uapi/linux/am437x-vpfe.h
 +++ b/include/uapi/linux/am437x-vpfe.h
 @@ -20,6 +20,7 @@
 
  #ifndef AM437X_VPFE_USER_H
  #define AM437X_VPFE_USER_H
 +#include linux/videodev2.h
 
  enum vpfe_ccdc_data_size {
   VPFE_CCDC_DATA_16BITS = 0,
 
 Do you think I should report this to LKML?

the v4l list, but otherwise yes.  you should be able to include any of these 
headers by themselves w/out things failing.  periodically i send one or two 
updates when i get around to it where a header fails to include another one it 
needs.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: trouble in kernel header inclusion in ./ioctls_gen.sh

[Mike Frysinger]

On 04 Mar 2015 02:21, Dmitry V. Levin wrote:
 On Tue, Mar 03, 2015 at 06:09:28PM -0500, Mike Frysinger wrote:
  On 04 Mar 2015 06:40, Masatake YAMATO wrote:
   When I run ioctls_gen.sh by hand, I got some errors:
   
   $ ./ioctls_gen.sh ~/var/linux/include ~/var/linux/arch/x86/include
   ...
   /home/yamato/var/linux/include/uapi/linux/am437x-vpfe.h:122:12: 
   error: ‘BASE_VIDIOC_PRIVATE’ undeclared (first use in this function)
 _IOW('V', BASE_VIDIOC_PRIVATE + 1, void *)
 ^
   /tmp/ioctls_sym.sh.DPfTZI/asm/ioctl.h:3:43: note: in definition of 
   macro ‘_IOC’
#define _IOC(dir,type,nr,size) dir, type, nr, size
   ...
   
   BASE_VIDIOC_PRIVATE is defined in linux/videodev2.h.
   
   With a following patch, ioctls_gen.sh works well without above error.
   
   diff --git a/include/uapi/linux/am437x-vpfe.h 
   b/include/uapi/linux/am437x-vpfe.h
   index 9b03033f..c28b4e4 100644
   --- a/include/uapi/linux/am437x-vpfe.h
   +++ b/include/uapi/linux/am437x-vpfe.h
   @@ -20,6 +20,7 @@
   
#ifndef AM437X_VPFE_USER_H
#define AM437X_VPFE_USER_H
   +#include linux/videodev2.h
   
enum vpfe_ccdc_data_size {
 VPFE_CCDC_DATA_16BITS = 0,
   
   Do you think I should report this to LKML?
  
  the v4l list, but otherwise yes.  you should be able to include any of 
  these 
  headers by themselves w/out things failing.  periodically i send one or two 
  updates when i get around to it where a header fails to include another one 
  it 
  needs.
 
 Unfortunately, ioctls_sym.sh couldn't wait for all kernel headers got
 fixed, so I had to load ioctls_sym.sh with a lot of workarounds.

right ... i wasn't trying to say that all the workarounds in strace should be 
punted
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

tl;dr: lets ship it

testing commit 600eafb6edcb89d6d602073edae97089c0a1e41a (v4.9-373-g600eafb)

native (build+tests):
vPASS:  alpha   64-bit/LSB  linux-3.18.1  kernel-headers-3.19.0  
glibc-2.20  gcc-4.9.2
vPASS:  armv7l  32-bit/LSB  linux-3.4.0-vapierkernel-headers-3.16.0  
glibc-2.19  gcc-4.7.3
vPASS:  i68632-bit/LSB  linux-3.18.4  kernel-headers-3.3.0   
glibc-2.17  gcc-4.7.2
vPASS:  ia6464-bit/LSB  linux-3.14.14-gentoo  kernel-headers-3.16.0  
glibc-2.19  gcc-4.7.4
vPASS:  parisc  32-bit/MSB  linux-3.16.2-gentoo   kernel-headers-3.16.0  
glibc-2.19  gcc-4.7.3
vPASS:  ppc 32-bit/MSB  linux-3.12.20-gentoo  kernel-headers-3.13.0  
glibc-2.21  gcc-4.8.4
vPASS:  ppc64   64-bit/MSB  linux-3.12.20-gentoo  kernel-headers-3.9.0   
glibc-2.17  gcc-4.7.3
vPASS:  s39032-bit/MSB  linux-3.19.0  kernel-headers-3.16.0  
glibc-2.19  gcc-4.8.3
vPASS:  s390x   64-bit/MSB  linux-3.19.0  kernel-headers-3.16.0  
glibc-2.19  gcc-4.8.3
vPASS:  sh4 32-bit/LSB  linux-2.6.30.9kernel-headers-3.13.0  
glibc-2.17  gcc-4.7.3
vPASS:  sparc   32-bit/MSB  linux-3.17.2  kernel-headers-3.13.0  
glibc-2.19  gcc-4.7.3
vPASS:  x86_64  32-bit/LSB  linux-3.18.4  kernel-headers-3.19.0  
glibc-2.21  gcc-4.9.2
vPASS:  x86_64  64-bit/LSB  linux-3.18.4  kernel-headers-3.4.0   
glibc-2.4   gcc-4.5.4

the runtime results for mips are slightly improved, but the n32 decoding 
continues to cause issues for o32/n64.  the stat32-v test on native n32 looks 
like a test issue (the stat test not properly hacking the kernel stat struct)
rather than an actual decode issue (the strace output looks OK to me).  so i 
guess we can just ignore that for now too.

cross (build only):
vPASS:  aarch64 64-bit/LSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.8.2
vPASS:  armv4   32-bit/LSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.8.0
vPASS:  bfin32-bit/LSB  cross  kernel-headers-3.5.0   uclibc-0.9.33  
gcc-4.5.3
vPASS:  bfin-fdpic  32-bit/LSB  cross  kernel-headers-3.5.0   uclibc-0.9.33  
gcc-4.5.3
vPASS:  m68k32-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.8.0
vPASS:  microblaze  32-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.20 
gcc-4.9.2
vPASS:  mips-n3232-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.6.4
vPASS:  mips-n6464-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.6.4
vPASS:  mips-o3232-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.6.4
vPASS:  sparc64 64-bit/MSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.6.4
vPASS:  tilegx  64-bit/LSB  cross  kernel-headers-3.19.0  glibc-2.21 
gcc-4.8.0

build warnings:
there's still random -Wsign-compare warnings, but i guess we don't care
about those
-mike


logs.tar.xz
Description: application/xz


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Where is tests-m32/Makefile.in?

[Mike Frysinger]

how about this.  strace doesn't actually require recent versions, so we can 
drop that part.

--- a/README-hacking
+++ b/README-hacking
@@ -2,8 +2,9 @@ Requirements
 
 If you use the GIT version of strace there will be some files missing
 that you need to build strace.  These files are generated by tools from
-the GNU Autoconf and Automake packages.  You need recent versions, which
-provide the `autoreconf -i' command that will do everything you need.
+the GNU Autoconf and Automake packages.
+
+Note: rather than run `autoreconf' directly, use the `./bootstrap' script.
 
 
 No more ChangeLog file
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 02 Mar 2015 22:22, Dmitry V. Levin wrote:
 On Mon, Mar 02, 2015 at 12:04:27PM -0500, Mike Frysinger wrote:
  On 02 Mar 2015 14:31, Dmitry V. Levin wrote:
   On s390, besides kernel bug with si_addr, all printed instruction pointers
   have 0x8000 bit set.  If it isn't a kernel bug (and it doesn't look 
   like
   one), then it's a strace bug in not taking some s390 address mapping
   feature into account.
  
  since it's not a regression and no one has complained yet, and we know s390 
  is 
  broken in at least one way, i think we just wait for the kernel guys to 
  respond 
  before we spend more time investigating.
 
 OK, what should we do with the test on s390/s390x then? xfail or skip?

based on the current thread, it looks like we'll want to do the same as the ipc 
check on ppc/sparc ... namely, make it into a SKIP.
-mike

--- a/tests/pc.c
+++ b/tests/pc.c
@@ -12,6 +12,14 @@ int main(void)
 {
const unsigned long pagesize = sysconf(_SC_PAGESIZE);
 
+#ifdef __s390__
+   /*
+* The si_addr field is unreliable:
+* https://marc.info/?l=linux-s390m=142515870124248w=2
+*/
+   return 77;
+#endif
+
/* write instruction pointer length to the log */
if (write(-1, NULL, 2 * sizeof(void *)) = 0)
return 77;


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 03 Mar 2015 00:44, Dmitry V. Levin wrote:
 On Mon, Mar 02, 2015 at 04:13:07PM -0500, Mike Frysinger wrote:
  --- a/tests/pc.c
  +++ b/tests/pc.c
  @@ -12,6 +12,14 @@ int main(void)
   {
  const unsigned long pagesize = sysconf(_SC_PAGESIZE);
   
  +#ifdef __s390__
  +   /*
  +* The si_addr field is unreliable:
  +* https://marc.info/?l=linux-s390m=142515870124248w=2
  +*/
  +   return 77;
  +#endif
 
 BTW, what does this w=2 parameter mean?  All marc.info URLs open fine
 without it, but virtually everybody use it anyway.

personally i dislike marc, so i'm not terribly familiar with it.  i blindly 
copied  pasted the URL from my browser.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 02 Mar 2015 23:05, Dmitry V. Levin wrote:
 On Mon, Mar 02, 2015 at 12:42:45AM -0500, Mike Frysinger wrote:
 [...]
  vFAIL: test; ppc/32-bit/MSB linux-3.12.20-gentoo kernel-headers-3.13.0 
  glibc-2.21 gcc-4.8.4
   kernel bug w/ipc
  vFAIL: test; sparc/32-bit/MSB linux-3.17.2 kernel-headers-3.13.0 glibc-2.19 
  gcc-4.7.3
   kernel bug w/ipc
 
 Is there any use in failing ipc_sem.test because of kernel bugs?
 strace tests are primarily for catching our bugs, not the kernel ones.

if we could dynamic XFAIL, that'd be best, but we can't.  i picked ERROR as that
seemed like the next appropriate one.  it does mean `make check` fails, but that
was the expectation.  if we want to not have `make check` fall down due to
issues outside of our control (like kernel bugs), then SKIP Is our only choice.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 02 Mar 2015 22:42, Dmitry V. Levin wrote:
 On Mon, Mar 02, 2015 at 12:04:27PM -0500, Mike Frysinger wrote:
  On 02 Mar 2015 14:31, Dmitry V. Levin wrote:
   On Mon, Mar 02, 2015 at 12:42:45AM -0500, Mike Frysinger wrote:
 - x32 statfs tracing of x86 binaries fails ?
   
   I'd like to see the log.  There are two test-suite.log files on x32,
   but only tests/test-suite.log is printed.
  
  FAIL: statfs
  
  
  execve(./statfs, [./statfs], [/* 44 vars */]) = 0
  [ Process PID=476 runs in 32 bit mode. ]
  access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or 
  directory)
  open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
  open(/lib/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
  statfs64(/proc/self/status, 84, {???}) = 0
  +++ exited with 0 +++
  statfs.test: failed test: ../strace -efile ./statfs failed to trace 
  statfs(64)? properly
  FAIL statfs.test (exit status: 1)
 
 I suppose this is the fix:
 
 --- a/statfs.c
 +++ b/statfs.c
 @@ -121,7 +121,7 @@ struct compat_statfs64 {
   uint32_t f_flags;
   uint32_t f_spare[4];
  }
 -#if defined(X86_64) || defined(IA64)
 +#if defined AARCH64 || defined X86_64 || defined X32|| defined IA64
__attribute__ ((packed, aligned(4)))
  #endif
  ;

x32 now passes w/that

obviously you'll fix the spacing after the X32 symbol ;)
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] tests: note the kernel configs for -yy options

[Mike Frysinger]

* tests/net-yy.test: Note CONFIG_INET_TCP_DIAG.
* tests/unix-yy.test: Note CONFIG_UNIX_DIAG.
---
 tests/net-yy.test  | 2 +-
 tests/unix-yy.test | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/net-yy.test b/tests/net-yy.test
index 8e6118a..47e3767 100755
--- a/tests/net-yy.test
+++ b/tests/net-yy.test
@@ -15,7 +15,7 @@ rm -f $LOG.* $LOG-*
 
 ./inet-accept-connect-send-recv || {
if [ $? -eq 77 ]; then
-   framework_skip_ 'PF_INET SOCK_STREAM is not available'
+   framework_skip_ 'PF_INET SOCK_STREAM (CONFIG_INET_TCP_DIAG) is 
not available'
else
fail_ 'inet-accept-connect-send-recv failed'
fi
diff --git a/tests/unix-yy.test b/tests/unix-yy.test
index 4a9b889..1845f55 100755
--- a/tests/unix-yy.test
+++ b/tests/unix-yy.test
@@ -20,7 +20,7 @@ addr=unix-yy-local-stream
 
 ./netlink_unix_diag || {
if [ $? -eq 77 ]; then
-   framework_skip_ 'NETLINK_SOCK_DIAG for unix domain sockets is 
not available'
+   framework_skip_ 'NETLINK_SOCK_DIAG for unix domain sockets 
(CONFIG_UNIX_DIAG) is not available'
else
fail_ 'netlink_unix_diag failed'
fi
-- 
2.3.1


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] tests: SKIP pc test on s390

[Mike Frysinger]

The s390 hardware can't support an exact si_addr, and the current kernels
don't handle text addresses correctly at all.  Until that improves, skip
the test on s390.

* tests/pc.c (main): Return 77 on s390 systems.
---
 tests/pc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tests/pc.c b/tests/pc.c
index a450c0d..4f12701 100644
--- a/tests/pc.c
+++ b/tests/pc.c
@@ -12,6 +12,14 @@ int main(void)
 {
const unsigned long pagesize = sysconf(_SC_PAGESIZE);
 
+#ifdef __s390__
+   /*
+* The si_addr field is unreliable:
+* https://marc.info/?l=linux-s390m=142515870124248w=2
+*/
+   return 77;
+#endif
+
/* write instruction pointer length to the log */
if (write(-1, NULL, 2 * sizeof(void *)) = 0)
return 77;
-- 
2.3.1


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 03 Mar 2015 03:20, Dmitry V. Levin wrote:
 OK, would you like to prepare commits for pc and ipc_sem tests?

OK
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] tests: skip ipc_sem on broken kernels

[Mike Frysinger]

Rather than trigger an ERROR which fails `make check`, go with SKIP
instead.  We don't want the testsuite failing due to kernel bugs.

* tests/ipc_sem.c (main): Change 99 to 77.
---
 tests/ipc_sem.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/ipc_sem.c b/tests/ipc_sem.c
index 3f2fbe7..ed4 100644
--- a/tests/ipc_sem.c
+++ b/tests/ipc_sem.c
@@ -44,6 +44,10 @@ done:
return rc;
 
 fail:
-   rc = errno == EFAULT ? 99 : 1;
+   /*
+* If the kernel failed, SKIP the test.  We want to ignore
+* such failures as they're out of scope for this project.
+*/
+   rc = errno == EFAULT ? 77 : 1;
goto done;
 }
-- 
2.3.1


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

mips test failures

[Mike Frysinger]

/strace/build-o3..., 
P4DIFFOPTS=-du, EDITOR=/bin/nano, PORTAGE_INST_GID=100, LESSCOLOR=0, 
GCC_BOUNDS_OPTS=-no-message, LANG=en_US.UTF8, ECHANGELOG_USER=Mike 
Frysinger ..., CROSTOOLS_GSUTIL=gsutil, PORTAGE_INST_UID=8282, 
HISTCONTROL=ignoreboth, HOME=/home/vapier, SHLVL=7, 
NACL_SDK_ROOT=/usr/local/src/nac..., TEST_LOGS=strace-f.log qual_sysc..., 
srcdir=../../tests, LOGNAME=vapier, LESS=-R --tabs=4 -M -#10, 
GCC_SPECS=, WINDOW=0, MAKE_TERMERR=/dev/pts/1, 
SSH_CONNECTION=172.29.73.122 532..., LESSOPEN=|lesspipe %s, 
INFOPATH=/usr/share/info:/usr/sh..., CONFIG_PROTECT=/usr/share/gnupg/..., 
_=../strace]) = 0
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
open(/lib/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
open(/etc/localtime, O_RDONLY|O_CLOEXEC) = 3
stat64(/etc/localtime, {st_dev=makedev(8, 4), st_ino=566856, 
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, 
st_blocks=8, st_size=2294, st_atime=2015/03/02-03:10:01, 
st_mtime=2015/01/31-06:23:33, st_ctime=2015/02/02-23:37:29}) = 0
stat64(/etc/localtime, {st_dev=makedev(8, 4), st_ino=566856, 
st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, 
st_blocks=8, st_size=2294, st_atime=2015/03/02-03:10:01, 
st_mtime=2015/01/31-06:23:33, st_ctime=2015/02/02-23:37:29}) = 0
+++ exited with 0 +++
stat32-v.test: failed test: ../strace -v -efile ./stat32 stat32_sample output 
mismatch
FAIL stat32-v.test (exit status: 1)

SKIP: unix-yy
=

unix-yy.test: framework skip: NETLINK_SOCK_DIAG for unix domain sockets is not 
available
SKIP unix-yy.test (exit status: 77)

FAIL: uid
=

error: getuid doesn't match
+++ exited with 0 +++
uid.test: failed test: unexpected output
FAIL uid.test (exit status: 1)

SKIP: uid16
===

uid16.test: framework skip: some uid or uid16_t syscalls are not available
SKIP uid16.test (exit status: 77)

SKIP: uid32
===

uid32.test: framework skip: some uid32 or uid_t syscalls are not available
SKIP uid32.test (exit status: 77)

FAIL: count
===

% time seconds  usecs/call callserrors syscall
-- --- --- - - 
  0.000.00   0 1   execve
  0.000.00   0 2   n32_read
  0.000.00   0 3   n32_open
  0.000.00   0 5   n32_close
  0.000.00   0 3   n32_fstat
  0.000.00   0 1   n32_lseek
  0.000.00   0 6   n32_mmap
  0.000.00   0 2   n32_mprotect
  0.000.00   0 1   n32_munmap
  0.000.00   0 3   n32_brk
  0.000.00   0 1 1 n32_access
  0.000.00   0 1   n32_nanosleep
  0.000.00   0 1   n32_uname
  0.000.00   0 1   n32_set_thread_area
-- --- --- - - 
100.000.0031 1 total
count.test: failed test: unexpected output from ../strace -c sleep 1
FAIL count.test (exit status: 1)

SKIP: strace-k
==

strace-k.test: skipped test: strace -k is not available
SKIP strace-k.test (exit status: 77)

=
   strace 4.9.0.367-d509: tests/test-suite.log
=

# TOTAL: 35
# PASS:  27
# SKIP:  5
# XFAIL: 0
# FAIL:  3
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: getdents
==

Line 1 does not match: +++ exited with 0 +++
Expected 3 lines, found 1 line(s).

+++ exited with 0 +++
getdents.test: failed test: strace -vegetdents,getdents64 failed to trace 
getdents/getdents64 properly
FAIL getdents.test (exit status: 1)

FAIL: stat
==

n32_open(0x771dc668, 0x8, 0x1)  = 3
n32_fstat(0x3, 0x7ffe2e50)  = 0
n32_mmap(0, 0x80f6, 0x1, 0x2, 0x3, 0)   = 1998258176
n32_close(0x3)  = 0
n32_open(0x771b7645, 0x8, 0x771eed18) = 3
n32_read(0x3, 0x7ffe3044, 0x200)= 512
n32_lseek(0x3, 0x2e8, 0)= 744
n32_read(0x3, 0x7ffe2f80, 0x20) = 32
n32_fstat(0x3, 0x7ffe2e20)  = 0
n32_mmap(0, 0x185f50, 0x5, 0x2002, 0x3, 0) = 1996652544
n32_mmap(0x771a4000, 0x8000, 0x3, 0x2012, 0x3, 0x16c000) = 1998209024
n32_mmap(0x771ac000, 0x1f50, 0x3, 0x812, 0x, 0) = 1998241792
n32_close(0x3)  = 0
n32_mmap(0, 0x4000, 0x3, 0x802, 0x, 0) = 1998471168
n32_open(0x7717f5b8, 0x82000, 0x) = 3
n32_fstat(0x3, 0x7ffe33b0)  = 0
n32_mmap(0, 0x1c4490, 0x1, 0x2, 0x3, 0) = 1994784768
n32_close(0x3)  = 0
n32_open(0x7ffe6a35, 0x2000, 0) = 3
n32_dup2(0x3, 0)= 0

[PATCH] clarify bootstrap-vs-autoreconf usage

[Mike Frysinger]

* README-hacking: Tell people to run ./boostrap.
---
 README-hacking | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/README-hacking b/README-hacking
index d2dfdd3..16d12c0 100644
--- a/README-hacking
+++ b/README-hacking
@@ -2,8 +2,9 @@ Requirements
 
 If you use the GIT version of strace there will be some files missing
 that you need to build strace.  These files are generated by tools from
-the GNU Autoconf and Automake packages.  You need recent versions, which
-provide the `autoreconf -i' command that will do everything you need.
+the GNU Autoconf and Automake packages.
+
+Note: rather than run `autoreconf' directly, use the `./bootstrap' script.
 
 
 No more ChangeLog file
-- 
2.3.1


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: alpha net-yy test failures due to port decode errors

[Mike Frysinger]

On 03 Mar 2015 02:24, Dmitry V. Levin wrote:
 On Mon, Mar 02, 2015 at 02:32:53PM -0500, Mike Frysinger wrote:
  done.  the first run is with the +20 hack while the second is w/out.
  
  TCP:[127.0.0.1:44261-127.0.0.1:41995]
  : 02  01  00  00  ac  e5  a4  0b | 7f  00  00  01  00  00  00  00  
  0010: 00  00  00  00  00  00  00  00 | 7f  00  00  01  00  00  00  00  
  0020: 00  00  00  00  00  00  00  00 | 00  00  00  00  00  b6  dc  f6  
  0030: 00  fc  ff  ff  00  00  00  00 | 00  00  00  00  00  00  00  00  
  0040: ed  03  00  00  53  b8  80  05 | 
  TCP:[127.0.0.1:39667-127.0.0.1:60672]
  : 02  01  00  00  9a  f3  ed  8e | 7f  00  00  01  00  00  00  00  
  0010: 00  00  00  00  00  00  00  00 | 7f  00  00  01  00  00  00  00  
  0020: 00  00  00  00  00  00  00  00 | 00  00  00  00  80  de  dc  f6  
  0030: 00  fc  ff  ff  00  00  00  00 | 00  00  00  00  00  00  00  00  
  0040: ed  03  00  00  9c  ab  80  05 | 
 
 In other words, the whole diag_msg struct is ok, diag_msg-id.idiag_sport
 is ok, but diag_msg-id.idiag_dport is NOT ok.
 
 Could you try this patch, please?
 
 --- a/socketutils.c
 +++ b/socketutils.c
 @@ -114,7 +114,7 @@ receive_responses(const int fd, const unsigned long inode,
 const char *proto_name,
 bool (* parser) (const char *, const void *, int, const 
 unsigned long))
  {
 - static char buf[8192];
 + static long buf[8192 / sizeof(long)];
   struct sockaddr_nl nladdr = {
   .nl_family = AF_NETLINK
   };

tests pass on alpha with this one change, so i guess that means it's ok ? :)
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: alpha net-yy test failures due to port decode errors

[Mike Frysinger]

On 03 Mar 2015 12:48, Masatake YAMATO wrote:
 On Tue, 3 Mar 2015 03:13:11 +0300, Dmitry V. Levin l...@altlinux.org 
 wrote:
   --- a/socketutils.c
   +++ b/socketutils.c
   @@ -114,7 +114,7 @@ receive_responses(const int fd, const unsigned long 
   inode,
  const char *proto_name,
  bool (* parser) (const char *, const void *, int, 
   const unsigned long))
{
   -static char buf[8192];
   +static long buf[8192 / sizeof(long)];
struct sockaddr_nl nladdr = {
.nl_family = AF_NETLINK
};
 
 ??? What does thie mean?
 The addresses of long buf and char buf differs?

afaict, it only changes alignment
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: alpha net-yy test failures due to port decode errors

[Mike Frysinger]

On 03 Mar 2015 13:32, Masatake YAMATO wrote:
 On Mon, 2 Mar 2015 23:20:12 -0500, Mike Frysinger wrote:
  On 03 Mar 2015 12:48, Masatake YAMATO wrote:
  On Tue, 3 Mar 2015 03:13:11 +0300, Dmitry V. Levin wrote:
--- a/socketutils.c
+++ b/socketutils.c
@@ -114,7 +114,7 @@ receive_responses(const int fd, const unsigned 
long inode,
const char *proto_name,
bool (* parser) (const char *, const void *, int, 
const unsigned long))
 {
- static char buf[8192];
+ static long buf[8192 / sizeof(long)];
  struct sockaddr_nl nladdr = {
  .nl_family = AF_NETLINK
  };
  
  ??? What does thie mean?
  The addresses of long buf and char buf differs?
  
  afaict, it only changes alignment
 
 alignment of buf itself?

correct.  a char[] can have any alignment while long[] has to have at least 
sizeof(long) on most systems (i.e. typically 4 on 32bit systems and 8 on 64bit).
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: alpha net-yy test failures due to port decode errors

[Mike Frysinger]

On 02 Mar 2015 17:10, Masatake YAMATO wrote:
 On Sun, 1 Mar 2015 04:05:33 -0500, Mike Frysinger vap...@gentoo.org wrote:
  it looks like the logic in socketutils.c is off a bit.  maybe some of the 
  buffers aren't correct ?  the large number marked static is a bit 
  concerning.
  if i hack inet_parse_response and increase zero_addr by an arbitrary 20 
  bytes,
  the port gets decoded correctly and the test starts passing.
 
 I'd like to know about your hack exactly.
 Could you show me it as a diff file?

--- a/socketutils.c
+++ b/socketutils.c
@@ -64,7 +64,7 @@ inet_parse_response(const char *proto_name, const void *data, 
int data_len,
const unsigned long inode)
 {
const struct inet_diag_msg *diag_msg = data;
-   static const char zero_addr[sizeof(struct in6_addr)];
+   static const char zero_addr[sizeof(struct in6_addr) + 20];
socklen_t addr_size, text_size;
 
if (diag_msg-idiag_inode != inode)
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 02 Mar 2015 14:31, Dmitry V. Levin wrote:
 On Mon, Mar 02, 2015 at 12:42:45AM -0500, Mike Frysinger wrote:
   - x32 statfs tracing of x86 binaries fails ?
 
 I'd like to see the log.  There are two test-suite.log files on x32,
 but only tests/test-suite.log is printed.

FAIL: statfs


execve(./statfs, [./statfs], [/* 44 vars */]) = 0
[ Process PID=476 runs in 32 bit mode. ]
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
open(/lib/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
statfs64(/proc/self/status, 84, {???}) = 0
+++ exited with 0 +++
statfs.test: failed test: ../strace -efile ./statfs failed to trace 
statfs(64)? properly
FAIL statfs.test (exit status: 1)

 On s390, besides kernel bug with si_addr, all printed instruction pointers
 have 0x8000 bit set.  If it isn't a kernel bug (and it doesn't look like
 one), then it's a strace bug in not taking some s390 address mapping
 feature into account.

since it's not a regression and no one has complained yet, and we know s390 is 
broken in at least one way, i think we just wait for the kernel guys to respond 
before we spend more time investigating.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 02 Mar 2015 18:13, Dmitry V. Levin wrote:
 On Mon, Mar 02, 2015 at 02:31:51PM +0300, Dmitry V. Levin wrote:
  On Mon, Mar 02, 2015 at 12:42:45AM -0500, Mike Frysinger wrote:
- x32 sysinfo.c has type warnings
  The fix seems to be as simple as sed -i s/%l/%j/g sysinfo.c.
 
 No, %ju is not a correct fix for 32-bit architectures,
 I had to use %llu format and cast to unsigned long long.

intmax_t should be 64bit on ILP32 systems.  it doesn't always mean you can 
avoid 
the cast though :(.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: alpha net-yy test failures due to port decode errors

[Mike Frysinger]

On 03 Mar 2015 02:56, Masatake YAMATO wrote:
 On Mon, 2 Mar 2015 04:48:13 -0500, Mike Frysinger vap...@gentoo.org wrote:
  --- a/socketutils.c
  +++ b/socketutils.c
  @@ -64,7 +64,7 @@ inet_parse_response(const char *proto_name, const void 
  *data, int data_len,
  const unsigned long inode)
   {
  const struct inet_diag_msg *diag_msg = data;
  -   static const char zero_addr[sizeof(struct in6_addr)];
  +   static const char zero_addr[sizeof(struct in6_addr) + 20];
  socklen_t addr_size, text_size;
   
  if (diag_msg-idiag_inode != inode)
 
 
 Thank you. but I just wonder why this has effects on the result.
 
 Could you try the patch and run tests on alpha?

done.  the first run is with the +20 hack while the second is w/out.

TCP:[127.0.0.1:44261-127.0.0.1:41995]
: 02  01  00  00  ac  e5  a4  0b | 7f  00  00  01  00  00  00  00  
0010: 00  00  00  00  00  00  00  00 | 7f  00  00  01  00  00  00  00  
0020: 00  00  00  00  00  00  00  00 | 00  00  00  00  00  b6  dc  f6  
0030: 00  fc  ff  ff  00  00  00  00 | 00  00  00  00  00  00  00  00  
0040: ed  03  00  00  53  b8  80  05 | 
TCP:[127.0.0.1:39667-127.0.0.1:60672]
: 02  01  00  00  9a  f3  ed  8e | 7f  00  00  01  00  00  00  00  
0010: 00  00  00  00  00  00  00  00 | 7f  00  00  01  00  00  00  00  
0020: 00  00  00  00  00  00  00  00 | 00  00  00  00  80  de  dc  f6  
0030: 00  fc  ff  ff  00  00  00  00 | 00  00  00  00  00  00  00  00  
0040: ed  03  00  00  9c  ab  80  05 | 

 If ss command, which is part of iproute2, is available on the alpha system,
 
 %  ss -n -t -p 
 State  Recv-Q Send-QLocal Address:Port  Peer 
 Address:Port 
 ESTAB  0  0  10.64.244.96:49945  
 10.64.255.1:631users:((gnome-settings-,pid=4724,fd=21))
 ESTAB  0  0 192.168.11.12:42019 
 96.43.148.82:443users:((firefox,pid=6415,fd=40))
 CLOSE-WAIT 1  0 192.168.11.12:58661   
 152.19.134.142:443   
 
 Older ss just opens /proc/net/tcp and read it.
 Newer ss uses netlink socket to get tcp socket informaton as strace -yy does.
 
 You can detect newer or older with /usr/bin/strace -e open ss -t.
 Older implentation may open /proc/net/tcp. Newer one may not.

`ss -nat` and `netstat -nat` match.  ss is using netlink here:
$ strace -eopen,socket ss -nat
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
open(/lib/libc.so.6.1, O_RDONLY|O_CLOEXEC) = 3
open(/proc/slabinfo, O_RDONLY)= 3
socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_SOCK_DIAG) = 3
...
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 02 Mar 2015 02:37, Dmitry V. Levin wrote:
 Can we fix all these issues by ignoring
 getresuid results in subsequent calls?

hmm, that also works.  there needs to be a comment in there so people don't try 
to clean it up/optimize, but otherwise an easy way to ignore the problem.  :)
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

alpha net-yy test failures due to port decode errors

[Mike Frysinger]

On 27 Feb 2015 01:06, Mike Frysinger wrote:
 vFAIL: test; alpha/64-bit/LSB linux-3.18.1 kernel-headers-3.19.0 glibc-2.20 
 gcc-4.9.2
 net-yy

there's some port decoding weirdness going on here.

the server does:
09:32:03.185497 accept(0TCP:[127.0.0.1:55298], ...
[pid 25534] 09:32:03.205029 ... accept resumed {sa_family=AF_INET, 
sin_port=htons(3), sin_addr=inet_addr(127.0.0.1)}, [16]) = 
1TCP:[127.0.0.1:55298-127.0.0.1:37632]

the 3 (0x9391) doesn't match the 37632 (0x9300).  running this multiple 
times shows the same issue -- the lower 16bits are always cleared in the later 
decoding lines.  checking the /proc/$pid/net/tcp lines shows that the 0x9391 is 
the correct port.

it looks like the logic in socketutils.c is off a bit.  maybe some of the 
buffers aren't correct ?  the large number marked static is a bit concerning.
if i hack inet_parse_response and increase zero_addr by an arbitrary 20 bytes,
the port gets decoded correctly and the test starts passing.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] tests/getdents: handle older getdents calls

[Mike Frysinger]

If the tools we use call older getdents syscalls where d_type isn't
passed back, or the arch is old (like Alpha) and can't pass back in
either version, make sure we don't fail.

* tests/getdents.awk (d_type_dir, d_type_reg): Accept DT_UNKNOWN.
---
 tests/getdents.awk | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/getdents.awk b/tests/getdents.awk
index f9dc64d..c230e26 100644
--- a/tests/getdents.awk
+++ b/tests/getdents.awk
@@ -11,8 +11,9 @@ BEGIN {
   d_name_1 = d_name=\\\.\
   d_name_2 = d_name=\\\.\\.\
   d_name_3 = d_name=\(An){127}Z\
-  d_type_dir = d_type=DT_DIR
-  d_type_reg = d_type=DT_REG
+  # Some older systems might not pass back d_type at all like Alpha.
+  d_type_dir = d_type=DT_(DIR|UNKNOWN)
+  d_type_reg = d_type=DT_(REG|UNKNOWN)
 
   dirent_1   = \\{ d_ino ,  d_off ,  d_reclen ,  d_name_1 ,  
d_type_dir \\}
   dirent_2   = \\{ d_ino ,  d_off ,  d_reclen ,  d_name_2 ,  
d_type_dir \\}
-- 
2.3.1


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Where is tests-m32/Makefile.in?

[Mike Frysinger]

On 02 Mar 2015 13:49, Masatake YAMATO wrote:
 How can I get tests-m32 directory?

run the bootstrap script instead of autotools directly
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Where is tests-m32/Makefile.in?

[Mike Frysinger]

On 02 Mar 2015 14:53, Masatake YAMATO wrote:
 On Mon, 2 Mar 2015 00:31:33 -0500, Mike Frysinger wrote:
  On 02 Mar 2015 13:49, Masatake YAMATO wrote:
  How can I get tests-m32 directory?
  
  run the bootstrap script instead of autotools directly
 
 Thank you. 
 
 How about adding following description to INSTALL?

i would point people to README-hacking and update that file to discuss the 
bootstrap script.  if we update INSTALL at all ... it's currently a generated 
file that comes from the autotools project ...
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Q: s390/s390x SIGSEGV SEGV_MAPERR reporting

[Mike Frysinger]

On 28 Feb 2015 23:09, Dmitry V. Levin wrote:
 On Sat, Feb 28, 2015 at 02:38:45PM -0500, Mike Frysinger wrote:
  On 28 Feb 2015 18:40, Dmitry V. Levin wrote:
   On Fri, Feb 27, 2015 at 01:06:22AM -0500, Mike Frysinger wrote:
vFAIL: test; s390/32-bit/MSB linux-3.18.1 kernel-headers-3.16.0 
glibc-2.19 gcc-4.8.3
FAIL: pc.test
0040-00401000 r-xp  5e:05 17513 /home/vapier/strace/tests/pc
00401000-00402000 r--p  5e:05 17513 /home/vapier/strace/tests/pc
[pid 24037] [fd4eaa6e] munmap(0x40, 8192) = 0
[pid 24037] [80400702] --- SIGSEGV {si_signo=SIGSEGV, 
si_code=SEGV_MAPERR, si_addr=0x40} ---
   
vFAIL: test; s390x/64-bit/MSB linux-3.18.1 kernel-headers-3.16.0 
glibc-2.19 gcc-4.8.3
8000-80001000 r-xp  5e:05 28901 /home/vapier/strace/tests/pc
80001000-80002000 r--p  5e:05 28901 /home/vapier/strace/tests/pc
[pid 17223] [03fffd1cf31a] munmap(0x8000, 8192) = 0
[pid 17223] [88f4] --- SIGSEGV {si_signo=SIGSEGV, 
si_code=SEGV_MAPERR, si_addr=0x8000} ---
   
   On all other architectures we tested si_addr matches instruction pointer.
   Could it be an s390/s390x kernel bug in SIGSEGV SEGV_MAPERR reporting?
  
  that does look like the case.  this change to the kernel lets the test pass:
  
  --- a/arch/s390/mm/fault.c
  +++ b/arch/s390/mm/fault.c
  @@ -282,7 +282,7 @@
  report_user_fault(regs, SIGSEGV);
  si.si_signo = SIGSEGV;
  si.si_code = si_code;
  -   si.si_addr = (void __user *)(regs-int_parm_long  __FAIL_ADDR_MASK);
  +   si.si_addr = (void __user *)regs-psw.addr;
  force_sig_info(SIGSEGV, si, current);
   }
 
 Thanks.  __FAIL_ADDR_MASK certainly shouldn't be applied in this case,
 passing unmodified regs-int_parm_long will fix s390x.  Not sure about
 replacing int_parm_long with psw.addr -- it would surely make the test
 pass, but whether strace is correct in printing unmodified psw.addr as
 instruction pointer on s390?

yeah, i noticed the nuances between data  insn based crashes when putting 
together a test case.  posted here:
https://marc.info/?l=linux-s390m=142515870124248w=2

i guess we just ignore the failure on s390/s390x and let upstream sort it out.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Q: ioctl files for x32

[Mike Frysinger]

On 28 Feb 2015 18:24, Dmitry V. Levin wrote:
 On Fri, Feb 27, 2015 at 01:06:22AM -0500, Mike Frysinger wrote:
  vFAIL: test; x86_64/32-bit/LSB linux-3.18.4 kernel-headers-3.19.0 
  glibc-2.21 gcc-4.9.2
  FAIL: ioctl
 
 Could you generate ioctls_{inc,arch}0.h files natively on x32?
 I suppose they would differ both from x86 and x86_64 versions.

ioctl on x32 runs through the compat_sys_ioctl entry point like x86.  attached 
is the generated header -- ioctls_arch.h was the same as x86_64/ioctls_arch0.h.

one thing to note with the tracing of the ioctl ABI is that the kernel might be 
broken and need fixing in some cases.  x32 is not widely deployed, so it hasn't 
been fully vetted yet :).
-mike


ioctls_inc.h.gz
Description: Binary data


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Q: s390/s390x SIGSEGV SEGV_MAPERR reporting

[Mike Frysinger]

On 28 Feb 2015 18:40, Dmitry V. Levin wrote:
 On Fri, Feb 27, 2015 at 01:06:22AM -0500, Mike Frysinger wrote:
  vFAIL: test; s390/32-bit/MSB linux-3.18.1 kernel-headers-3.16.0 glibc-2.19 
  gcc-4.8.3
  FAIL: pc.test
  0040-00401000 r-xp  5e:05 17513 /home/vapier/strace/tests/pc
  00401000-00402000 r--p  5e:05 17513 /home/vapier/strace/tests/pc
  [pid 24037] [fd4eaa6e] munmap(0x40, 8192) = 0
  [pid 24037] [80400702] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, 
  si_addr=0x40} ---
 
  vFAIL: test; s390x/64-bit/MSB linux-3.18.1 kernel-headers-3.16.0 glibc-2.19 
  gcc-4.8.3
  8000-80001000 r-xp  5e:05 28901 /home/vapier/strace/tests/pc
  80001000-80002000 r--p  5e:05 28901 /home/vapier/strace/tests/pc
  [pid 17223] [03fffd1cf31a] munmap(0x8000, 8192) = 0
  [pid 17223] [88f4] --- SIGSEGV {si_signo=SIGSEGV, 
  si_code=SEGV_MAPERR, si_addr=0x8000} ---
 
 On all other architectures we tested si_addr matches instruction pointer.
 Could it be an s390/s390x kernel bug in SIGSEGV SEGV_MAPERR reporting?

that does look like the case.  this change to the kernel lets the test pass:

--- a/arch/s390/mm/fault.c
+++ b/arch/s390/mm/fault.c
@@ -282,7 +282,7 @@
report_user_fault(regs, SIGSEGV);
si.si_signo = SIGSEGV;
si.si_code = si_code;
-   si.si_addr = (void __user *)(regs-int_parm_long  __FAIL_ADDR_MASK);
+   si.si_addr = (void __user *)regs-psw.addr;
force_sig_info(SIGSEGV, si, current);
 }
 

i'll contact upstream on the topic.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 27 Feb 2015 01:06, Mike Frysinger wrote:
 i'll look into the ppc/sparc ipc_sem failures.  i suspect it's a 
 kernel/system 
 config thing we need to test for and SKIP.

in both cases it's a 32bit prog running under a 64bit kernel.  i suspect the 
kernel is broken but no one noticed because who cares about ipc :).  the same 
ppc system passes tests with a 64bit userland.  i don't have sparc 64bit 
userland to check.

i tried messing with setarch and passing in -XBIST3LZR, and now running ipc_sem 
has created an unkillable process :D.  which makes me think even more that 
there's a kernel mismatch here.

maybe we should use errno==EFAULT as a marker ?  a non-fatal ERROR would be 
nice, but the test framework doesn't support such a thing.  you can't do 
XFAIL/PASS dynamically with the automake framework.  maybe something like the
attached patch ?


here is the ppc one:
$ strace ./ipc_sem
execve(./ipc_sem, [./ipc_sem], [/* 27 vars */]) = 0
brk(0)  = 0x10012000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf7f4d000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=15865, ...}) = 0
mmap(NULL, 15865, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f49000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, 
\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\2\35\254\0\0\0004..., 512) 
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1471360, ...}) = 0
mmap(0xfe77000, 1541424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) 
= 0xfe77000
mprotect(0xffd8000, 65536, PROT_NONE)   = 0
mmap(0xffe8000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x161000) = 0xffe8000
mmap(0xffed000, 9520, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xffed000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf7f48000
mprotect(0xffe8000, 16384, PROT_READ)   = 0
mprotect(0x1001, 4096, PROT_READ)   = 0
mprotect(0xf7f4e000, 4096, PROT_READ)   = 0
munmap(0xf7f49000, 15865)   = 0
semget(IPC_PRIVATE, 1, 0600)= 2752514
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf7f4c000
write(1, semget\\(IPC_PRIVATE, 1, 0600\\) +..., 42semget\(IPC_PRIVATE, 1, 
0600\) += 2752514
) = 42
semctl(2752514, 0, IPC_64|IPC_STAT, 0xffce4e3c) = 0
write(1, semctl\\(2752514, 0, IPC_STAT, 0x..., 48semctl\(2752514, 0, 
IPC_STAT, 0xffce4ec0\) += 0
) = 48
semctl(0, 0, SEM_INFO, 0xffce4e3c)  = -1 EFAULT (Bad address)
semctl(2752514, 0, IPC_RMID, 0xffce4e3c) = 0
write(1, semctl\\(2752514, 0, IPC_RMID, 0\\..., 39semctl\(2752514, 0, 
IPC_RMID, 0\) += 0
) = 39
exit_group(1)   = ?
+++ exited with 1 +++


sparc one looks largely the same:
$ strace ./ipc_sem
execve(./ipc_sem, [./ipc_sem], [/* 45 vars */]) = 0
brk(0)  = 0x24000
uname({sys=Linux, node=bender, ...}) = 0
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=21673, ...}) = 0
mmap(NULL, 21673, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf798c000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY|O_CLOEXEC) = 3
read(3, \177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\22\0\0\0\1\0\2\2@\0\0\0004..., 
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1481056, ...}) = 0
mmap(NULL, 1555224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xf77e8000
mprotect(0xf795, 57344, PROT_NONE)  = 0
mmap(0xf795e000, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x166000) = 0xf795e000
mmap(0xf7962000, 6936, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xf7962000
close(3)= 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf798a000
mprotect(0xf795e000, 8192, PROT_READ)   = 0
mprotect(0x2, 8192, PROT_READ)  = 0
mprotect(0xf7992000, 8192, PROT_READ)   = 0
munmap(0xf798c000, 21673)   = 0
semget(IPC_PRIVATE, 1, 0600)= 294912
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xf799
write(1, semget\\(IPC_PRIVATE, 1, 0600\\) +..., 41semget\(IPC_PRIVATE, 1, 
0600\) += 294912
) = 41
semctl(294912, 0, IPC_64|IPC_STAT, 0xffdb7138) = -1 EFAULT (Bad address)
semctl(294912, 0, IPC_64|IPC_RMID, 0xffdb7138) = 0
write(1, semctl\\(294912, 0, IPC_RMID, 0\\)..., 38semctl\(294912, 0, 
IPC_RMID, 0\) += 0
) = 38
exit_group(1)   = ?
+++ exited with 1 +++
-mike
From e85573dfed6f936baa6a6e295d7c2ef584bde33d Mon Sep 17 00:00:00 2001
From

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 27 Feb 2015 07:52, Dmitry V. Levin wrote:
 On Thu, Feb 26, 2015 at 11:31:59PM -0500, Mike Frysinger wrote:
  On 27 Feb 2015 05:30, Dmitry V. Levin wrote:
   On Thu, Feb 26, 2015 at 05:56:43PM -0500, Mike Frysinger wrote:
detach-stopped.test.tmp contains just this:
Process 1267 attached
restart_syscall(... resuming interrupted call ...
   
   That is, either kill -STOP failed to stop sleep or PTRACE_EVENT_STOP
   hasn't been delivered to strace.  How could it be?
  
  tl;dr: sent you a patch
 
 Thanks, merged.
 
 In short, strace didn't support PTRACE_EVENT_STOP functionality
 on linux 3.[123], and is not going to support it on these ABI-incompatible
 kernels unless somebody implements runtime detection of PTRACE_EVENT_STOP.

sure, but building binaries against older headers shouldn't generally produce
a broken binary when run under newer kernels.  imo there's a reasonable middle
ground to be had here.  duplicating the entire header base to protect ourselves 
against things is certainly crazy.  it'll be a judgement call every time we run
into these things.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

the sh4 failure looks like a race probably due to a loaded system.  i re-ran 
the 
one failing test when it was quiet and it passed.

i'll look into the ppc/sparc ipc_sem failures.  i suspect it's a kernel/system 
config thing we need to test for and SKIP.

testing commit d32e1b9dde3fdbd723a672549d752665f7e72329 (v4.9-351-gd32e1b9)

native (build+tests):
vFAIL: test; alpha/64-bit/LSB linux-3.18.1 kernel-headers-3.19.0 glibc-2.20 
gcc-4.9.2
vFAIL: test; ppc/32-bit/MSB linux-3.12.20-gentoo kernel-headers-3.13.0 
glibc-2.21 gcc-4.8.4
vFAIL: test; s390/32-bit/MSB linux-3.18.1 kernel-headers-3.16.0 glibc-2.19 
gcc-4.8.3
vFAIL: test; s390x/64-bit/MSB linux-3.18.1 kernel-headers-3.16.0 glibc-2.19 
gcc-4.8.3
vFAIL: test; sh4/32-bit/LSB linux-2.6.30.9 kernel-headers-3.13.0 glibc-2.17 
gcc-4.7.3
vFAIL: test; sparc/32-bit/MSB linux-3.17.2 kernel-headers-3.13.0 glibc-2.19 
gcc-4.7.3
vFAIL: test; x86_64/32-bit/LSB linux-3.18.4 kernel-headers-3.19.0 glibc-2.21 
gcc-4.9.2
vPASS: armv7l/32-bit/LSB linux-3.4.0-vapier kernel-headers-3.16.0 glibc-2.19 
gcc-4.7.3
vPASS: i686/32-bit/LSB linux-3.18.4 kernel-headers-3.3.0 glibc-2.17 gcc-4.7.2
vPASS: ia64/64-bit/LSB linux-3.14.14-gentoo kernel-headers-3.16.0 glibc-2.19 
gcc-4.7.4
vPASS: parisc/32-bit/MSB linux-3.16.2-gentoo kernel-headers-3.16.0 glibc-2.19 
gcc-4.7.3
vPASS: ppc64/64-bit/MSB linux-3.12.20-gentoo kernel-headers-3.9.0 glibc-2.17 
gcc-4.7.3
vPASS: x86_64/64-bit/LSB linux-3.18.4 kernel-headers-3.4.0 glibc-2.4 gcc-4.5.4

cross (build only):
vFAIL: build; m68k/32-bit/MSB cross kernel-headers-3.19.0 glibc-2.21 gcc-4.8.0
vPASS: aarch64/64-bit/LSB cross kernel-headers-3.19.0 glibc-2.21 gcc-4.8.2
vPASS: armv4/32-bit/LSB cross kernel-headers-3.19.0 glibc-2.21 gcc-4.8.0
vPASS: bfin/32-bit/LSB cross kernel-headers-3.5.0 uclibc-0.9.33 gcc-4.5.3
vPASS: bfin-fdpic/32-bit/LSB cross kernel-headers-3.5.0 uclibc-0.9.33 gcc-4.5.3
vPASS: microblaze/32-bit/MSB cross kernel-headers-3.19.0 glibc-2.20 gcc-4.9.2
vPASS: mips-n32/32-bit/MSB cross kernel-headers-3.19.0 glibc-2.21 gcc-4.6.4
vPASS: mips-n64/64-bit/MSB cross kernel-headers-3.19.0 glibc-2.21 gcc-4.6.4
vPASS: mips-o32/32-bit/MSB cross kernel-headers-3.19.0 glibc-2.21 gcc-4.6.4
vPASS: sparc64/64-bit/MSB cross kernel-headers-3.19.0 glibc-2.21 gcc-4.6.4
vPASS: tilegx/64-bit/LSB cross kernel-headers-3.19.0 glibc-2.21 gcc-4.8.0


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

would help if i attached the logs ;)
-mike


logs.tar.xz
Description: application/xz


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 27 Feb 2015 01:23, Dmitry V. Levin wrote:
 On Thu, Feb 26, 2015 at 01:10:39AM -0500, Mike Frysinger wrote:
  vFAIL: test; i686/32-bit/LSB linux-3.18.4 kernel-headers-3.3.0 glibc-2.17 
  gcc-4.7.2
 
 I'd like to know how to reproduce this.

this is just a standard 32-bit x86 userland system with a 64-bit x86_64 kernel 
(which is itself vanilla from kernel.org).  nothing special i can see really.

i've verified it's not a load issue (as my things normally build+test in 
parallel) -- when i run `make check TESTS=detach-stopped.test` when things are 
quiet, it still fails.

i manually added set -x to the top of the file -- that log is attached.  should 
init.sh run `set -x` mode all the time to make the failing logs a bit more 
helpful in edge cases like this ?

detach-stopped.test.tmp contains just this:
Process 1267 attached
restart_syscall(... resuming interrupted call ...
-mike
+ . ./init.sh
++ ME_=detach-stopped.test
++ check_prog cat
++ type cat
++ check_prog rm
++ type rm
++ LOG=detach-stopped.test.tmp
++ rm -f detach-stopped.test.tmp
++ : ../strace
++ : 60
++ : 'sleep 1'
+ kill -0 1260
+ check_prog grep
+ type grep
+ check_prog sleep
+ type sleep
+ ../strace -d -enone /
+ grep -F -x 'PTRACE_SEIZE doesn'\''t work' detach-stopped.test.tmp
+ set -e
+ rm -f detach-stopped.test.tmp
+ '[' -s detach-stopped.test.tmp ']'
+ kill -0 1267
+ sleep 1
+ ./set_ptracer_any sleep 120
+ '[' -s detach-stopped.test.tmp ']'
+ tracee_pid=1267
+ kill -STOP 1267
+ rm -f detach-stopped.test.tmp
+ grep -F 'Process 1267 attached' detach-stopped.test.tmp
+ ../strace -p 1267
+ kill -0 1270
+ sleep 1
+ grep -F 'Process 1267 attached' detach-stopped.test.tmp
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp
+ kill -0 1270
+ sleep 1
+ grep -F -e '--- stopped by ' detach-stopped.test.tmp

Re: [PATCH] ia64: fix up builds after 16bit uuid support

[Mike Frysinger]

On 26 Feb 2015 23:14, Dmitry V. Levin wrote:
 On Thu, Feb 26, 2015 at 02:15:33AM -0500, Mike Frysinger wrote:
  --- a/linux/ia64/syscallent.h
  +++ b/linux/ia64/syscallent.h
  @@ -26,6 +26,9 @@
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
   
  +/* Undo any defines that an earlier dummy.h inclusion setup.  */
  +#undef sys_stime
  +
   /*
* IA-32 syscalls that have pointer arguments which are incompatible
* with 64-bit layout get redirected to printargs.
 
 These ia64 redefinitions to printargs and back are very fragile...

certainly, but i'm not trying to rock the boat here :).  the code as-is doesn't 
build cleanly today.
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: [PATCH] hppa: fix fanotify_mark decoding

[Mike Frysinger]

On 27 Feb 2015 00:36, Dmitry V. Levin wrote:
 On Thu, Feb 26, 2015 at 02:16:13PM -0500, Mike Frysinger wrote:
  The parisc kernel has some legacy baggage here and decodes the 64bit
  field in the reverse order.  Handle it in strace too.
  
  * fanotify.c [HPPA] (sys_fanotify_mark): Reverse the mask bits.
  ---
   fanotify.c | 4 
   1 file changed, 4 insertions(+)
  
  diff --git a/fanotify.c b/fanotify.c
  index e421b01..63816b8 100644
  --- a/fanotify.c
  +++ b/fanotify.c
  @@ -52,6 +52,10 @@ sys_fanotify_mark(struct tcb *tcp)
   * but kernel uses the lower 32 bits only.
   */
  argn = getllval(tcp, mask, 2);
  +#ifdef HPPA
  +   /* Parsic is weird.  See arch/parisc/kernel/sys_parisc32.c.  */
  +   mask = (mask  32) | (mask  32);
  +#endif
 
 Really weird.  What if they stop using sys_parisc32.c?

then things would go back to the way they were ;).  this shim was added in 
response to what glibc was doing for a long time, so i don't expect them to 
rebreak the ABI:

commit ab8a261ba5e2dd9206da640de5870cc31d568a7c
Author: Helge Deller del...@gmx.de
Date:   Thu Jul 10 18:07:17 2014 +0200

parisc: fix fanotify_mark() syscall on 32bit compat kernel

On parisc we can not use the existing compat implementation for 
fanotify_mark()
because for the 64bit mask parameter the higher and lower 32bits are ordered
differently than what the compat function expects from big endian
architectures.

Specifically:
It finally turned out, that on hppa we end up with different assignments
of parameters to kernel arguments depending on if we call the glibc
wrapper function
 int fanotify_mark (int __fanotify_fd, unsigned int __flags,
uint64_t __mask, int __dfd, const char *__pathname);
or directly calling the syscall manually
 syscall(__NR_fanotify_mark, ...)

Reason is, that the syscall() function is implemented as C-function and
because we now have the sysno as first parameter in front of the other
parameters the compiler will unexpectedly add an empty paramenter in
front of the u64 value to ensure the correct calling alignment for 64bit
values.
This means, on hppa you can't simply use syscall() to call the kernel
fanotify_mark() function directly, but you have to use the glibc
function instead.

This patch fixes the kernel in the hppa-arch specifc coding to adjust
the parameters in a way as if userspace calls the glibc wrapper function
fanotify_mark().

 BTW, syscall names defined in linux/hppa/syscallent.h are out of sync with 
 arch/parisc/include/uapi/asm/unistd.h; this is why stat32-v.test fails
 there.  And it's not a recent regression, we just didn't tested these
 things before.

did you want me to go through it ?
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Preparing for the next release: call for testing

[Mike Frysinger]

On 27 Feb 2015 05:30, Dmitry V. Levin wrote:
 On Thu, Feb 26, 2015 at 05:56:43PM -0500, Mike Frysinger wrote:
  detach-stopped.test.tmp contains just this:
  Process 1267 attached
  restart_syscall(... resuming interrupted call ...
 
 That is, either kill -STOP failed to stop sleep or PTRACE_EVENT_STOP
 hasn't been delivered to strace.  How could it be?

tl;dr: sent you a patch

doing it by hand shows the same behavior:
$ ./set_ptracer_any sleep 10 
$ kill -STOP $!
$ ../strace -p $!
Process 21534 attached
restart_syscall(... resuming interrupted call ...^CProcess 21534 detached
 detached ...

if i use previous versions, it works:
$ strace -V
strace -- version 4.6
$ strace -p $!
Process 21534 attached - interrupt to quit
--- {si_signo=SIGSTOP, si_code=SI_USER, si_value={int=4294303860, 
ptr=0xfff5e074}} (Stopped (signal)) ---
--- Stopped (signal) by SIGSTOP ---
restart_syscall(... resuming interrupted call ...^C unfinished ...
Process 21534 detached

$ strace -V
strace -- version 4.9
$ strace -p $!
Process 21534 attached
--- stopped by SIGSTOP ---
^CProcess 21534 detached

bisecting shows fadf379b8e3618585cecad447867af27930ac5e3.  which looks a little 
odd, but seems pretty reliable on my end.  reverting defs.h  strace.c in that 
patch gets me a working version.  diving further, this gets me a working 
version with ToT:
--- a/strace.c
+++ b/strace.c
@@ -45,6 +45,9 @@
 
 #include ptrace.h
 
+#undef PTRACE_EVENT_STOP
+#define PTRACE_EVENT_STOP  128
+
 /* In some libc, these aren't declared. Do it ourself: */
 extern char **environ;
 extern int optind;

this is because the linux-headers i have come from linux-3.3 and do:
/usr/include/linux/ptrace.h:#define PTRACE_EVENT_STOP   7

looking at the kernel history, this value was broken in linux 3.1, 3.2, and 
3.3.  
it was fixed here for 3.4:
commit 5cdf389aee90109e2e3d88085dea4dd5508a3be7
Author: Denys Vlasenko vda.li...@googlemail.com
Date:   Fri Mar 23 15:02:42 2012 -0700

ptrace: renumber PTRACE_EVENT_STOP so that future new options and events 
can match

i guess my decision to try and keep a variety of toolchain/kernel versions has 
paid off :).
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] handle broken PTRACE_EVENT_STOP values

[Mike Frysinger]

For a few linux releases (3.1 through 3.3), this define in the exported
headers were broken.  Undefine it that's the case.

* ptrace.h [PTRACE_EVENT_STOP]: Undefine if PTRACE_EVENT_STOP is 7.
---
 ptrace.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ptrace.h b/ptrace.h
index 1a5414d..065cbda 100644
--- a/ptrace.h
+++ b/ptrace.h
@@ -50,6 +50,12 @@ extern long ptrace(int, int, char *, long);
 #ifndef PTRACE_EVENT_SECCOMP
 # define PTRACE_EVENT_SECCOMP  7
 #endif
+#ifdef PTRACE_EVENT_STOP
+/* Linux 3.1 - 3.3 releases had a broken value.  It was fixed in 3.4.  */
+# if PTRACE_EVENT_STOP == 7
+#  undef PTRACE_EVENT_STOP
+# endif
+#endif
 #ifndef PTRACE_EVENT_STOP
 # define PTRACE_EVENT_STOP 128
 #endif
-- 
2.3.0


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] fix cross-compiling of ioctlsort

[Mike Frysinger]

Use the AX_PROG_CC_FOR_BUILD helper to set up build settings when cross
compiling.  This way ioctlsort uses the build tools all the time.

* configure.ac: Call AX_PROG_CC_FOR_BUILD.
* Makefile.am (ioctlsort_CC): Set to CC_FOR_BUILD.
(ioctlsort_CPPFLAGS): Change CPPFLAGS to CPPFLAGS_FOR_BUILD.
(ioctlsort_CFLAGS): Change CFLAGS to CFLAGS_FOR_BUILD.
(ioctlsort_LDFLAGS): Change LDFLAGS to LDFLAGS_FOR_BUILD.
(ioctlsort_LD): Delete.
(ioctlsort%): Change to ioctlsort%$(BUILD_EXEEXT).  Use ioctlsort_CFLAGS.
* m4/ax_prog_cc_for_build.m4: Import from the autoconf-archive package.
---
 Makefile.am|  13 +++--
 configure.ac   |   1 +
 m4/ax_prog_cc_for_build.m4 | 125 +
 3 files changed, 132 insertions(+), 7 deletions(-)
 create mode 100644 m4/ax_prog_cc_for_build.m4

diff --git a/Makefile.am b/Makefile.am
index bc8e357..3fd7715 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -403,13 +403,12 @@ news-check: NEWS
exit 1; \
fi
 
-ioctlsort_CC = $(CC)
+ioctlsort_CC = $(CC_FOR_BUILD)
 ioctlsort_DEFS = $(DEFS)
 ioctlsort_INCLUDES = $(DEFAULT_INCLUDES) $(INCLUDES)
-ioctlsort_CPPFLAGS = $(AM_CPPFLAGS) $(CPPFLAGS)
-ioctlsort_CFLAGS = $(AM_CFLAGS) $(CFLAGS)
-ioctlsort_LD = $(CCLD)
-ioctlsort_LDFLAGS = $(AM_LDFLAGS) $(LDFLAGS)
+ioctlsort_CPPFLAGS = $(AM_CPPFLAGS) $(CPPFLAGS_FOR_BUILD)
+ioctlsort_CFLAGS = $(AM_CFLAGS) $(CFLAGS_FOR_BUILD)
+ioctlsort_LDFLAGS = $(AM_LDFLAGS) $(LDFLAGS_FOR_BUILD)
 
 ioctls_inc_h = $(wildcard $(srcdir)/$(OS)/$(ARCH)/ioctls_inc*.h)
 ioctlent_h = $(patsubst 
$(srcdir)/$(OS)/$(ARCH)/ioctls_inc%,ioctlent%,$(ioctls_inc_h))
@@ -419,8 +418,8 @@ CLEANFILES = $(ioctlent_h)
 ioctlent%.h: ioctlsort%
./$  $@
 
-ioctlsort%: ioctlsort%.o
-   $(ioctlsort_LD) $(ioctlsort_LDFLAGS) $ -o $@
+ioctlsort%$(BUILD_EXEEXT): ioctlsort%.o
+   $(ioctlsort_CC) $(ioctlsort_CFLAGS) $(ioctlsort_LDFLAGS) $ -o $@
 
 ioctlsort%.o: ioctls_all%.h $(srcdir)/ioctlsort.c
$(ioctlsort_CC) $(ioctlsort_DEFS) $(ioctlsort_INCLUDES) 
$(ioctlsort_CPPFLAGS) $(ioctlsort_CFLAGS) -DIOCTLSORT_INC=\$\ -c -o $@ 
$(srcdir)/ioctlsort.c
diff --git a/configure.ac b/configure.ac
index b21941e..6ea90bc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -11,6 +11,7 @@ AM_MAINTAINER_MODE
 AC_CANONICAL_HOST
 
 AC_PROG_CC
+AX_PROG_CC_FOR_BUILD
 AC_USE_SYSTEM_EXTENSIONS
 
 AC_MSG_CHECKING([for supported architecture])
diff --git a/m4/ax_prog_cc_for_build.m4 b/m4/ax_prog_cc_for_build.m4
new file mode 100644
index 000..77fd346
--- /dev/null
+++ b/m4/ax_prog_cc_for_build.m4
@@ -0,0 +1,125 @@
+# ===
+#   http://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
+# ===
+#
+# SYNOPSIS
+#
+#   AX_PROG_CC_FOR_BUILD
+#
+# DESCRIPTION
+#
+#   This macro searches for a C compiler that generates native executables,
+#   that is a C compiler that surely is not a cross-compiler. This can be
+#   useful if you have to generate source code at compile-time like for
+#   example GCC does.
+#
+#   The macro sets the CC_FOR_BUILD and CPP_FOR_BUILD macros to anything
+#   needed to compile or link (CC_FOR_BUILD) and preprocess (CPP_FOR_BUILD).
+#   The value of these variables can be overridden by the user by specifying
+#   a compiler with an environment variable (like you do for standard CC).
+#
+#   It also sets BUILD_EXEEXT and BUILD_OBJEXT to the executable and object
+#   file extensions for the build platform, and GCC_FOR_BUILD to `yes' if
+#   the compiler we found is GCC. All these variables but GCC_FOR_BUILD are
+#   substituted in the Makefile.
+#
+# LICENSE
+#
+#   Copyright (c) 2008 Paolo Bonzini bonz...@gnu.org
+#
+#   Copying and distribution of this file, with or without modification, are
+#   permitted in any medium without royalty provided the copyright notice
+#   and this notice are preserved. This file is offered as-is, without any
+#   warranty.
+
+#serial 8
+
+AU_ALIAS([AC_PROG_CC_FOR_BUILD], [AX_PROG_CC_FOR_BUILD])
+AC_DEFUN([AX_PROG_CC_FOR_BUILD], [dnl
+AC_REQUIRE([AC_PROG_CC])dnl
+AC_REQUIRE([AC_PROG_CPP])dnl
+AC_REQUIRE([AC_EXEEXT])dnl
+AC_REQUIRE([AC_CANONICAL_HOST])dnl
+
+dnl Use the standard macros, but make them use other variable names
+dnl
+pushdef([ac_cv_prog_CPP], ac_cv_build_prog_CPP)dnl
+pushdef([ac_cv_prog_gcc], ac_cv_build_prog_gcc)dnl
+pushdef([ac_cv_prog_cc_works], ac_cv_build_prog_cc_works)dnl
+pushdef([ac_cv_prog_cc_cross], ac_cv_build_prog_cc_cross)dnl
+pushdef([ac_cv_prog_cc_g], ac_cv_build_prog_cc_g)dnl
+pushdef([ac_cv_exeext], ac_cv_build_exeext)dnl
+pushdef([ac_cv_objext], ac_cv_build_objext)dnl
+pushdef([ac_exeext], ac_build_exeext)dnl
+pushdef([ac_objext], ac_build_objext)dnl
+pushdef([CC], CC_FOR_BUILD)dnl
+pushdef([CPP], CPP_FOR_BUILD)dnl
+pushdef([CFLAGS], CFLAGS_FOR_BUILD)dnl
+pushdef([CPPFLAGS], CPPFLAGS_FOR_BUILD)dnl

[PATCH] bootstrap: always set up test dirs

[Mike Frysinger]

When files get updated, the bootstrap script should make sure the
parallel dirs are kept in sync.

* bootstrap: Always generate the test$m.  Clean up symlinks first.
Don't link in Makefile.in files.
---
 bootstrap | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/bootstrap b/bootstrap
index 9624fec..86598b2 100755
--- a/bootstrap
+++ b/bootstrap
@@ -1,13 +1,14 @@
 #!/bin/sh -eu
 
 for m in -m32 -mx32; do
-   mkdir tests$m ||
-   continue
+   mkdir -p tests$m
+   find tests$m -type l -delete
sed s/^AM_CFLAGS[[:space:]]*=.*/ $m/ \
tests/Makefile.am  tests$m/Makefile.am
for f in tests/*; do
-   [ ${f##*/} != Makefile.am ] ||
-   continue
+   case ${f##*/} in
+   Makefile.am|Makefile.in) continue;;
+   esac
ln -s ../$f tests$m/
done
 done
-- 
2.3.0


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Q: alternative hosting for strace-devel mailing list

[Mike Frysinger]

On 25 Feb 2015 13:06, Philippe Ombredanne wrote:
 On Wed, Feb 25, 2015 at 12:59 PM, Dmitry V. Levin l...@altlinux.org wrote:
  On Tue, Feb 24, 2015 at 07:51:52AM +0300, Dmitry V. Levin wrote:
  I've configured strace.git mirrors where I push updates when
  git.code.sf.net/p/strace/code.git is not available:
 
  https://github.com/ldv-alt/strace.git
  git://git.altlinux.org/people/ldv/public/strace.git
 
  This and other email messages were silently delayed by sourceforge.net for
  many hours.  For example, for this email it took about 40 hours to reach
  the mailing list:
 
  Received: from localhost ([127.0.0.1] helo=sfs-ml-1.v29.ch3.sourceforge.com)
  by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
  (envelope-from strace-devel-boun...@lists.sourceforge.net)
  id 1YQiY9-0003eH-LU; Wed, 25 Feb 2015 20:27:17 +
  Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
  helo=mx.sourceforge.net)
  by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
  (envelope-from l...@altlinux.org) id 1YQ7TU-0004c1-BO
  for strace-devel@lists.sourceforge.net; Tue, 24 Feb 2015 04:52:00 
  +
 
  I suppose there should be a more reliable hosting for mailing lists than
  sourceforge.net.  Any ideas?
 
 I do not know of any satisfying alternative. Google groups is rather crass.
 
 We could reach out to kernel.org or some Linux distro or some other
 established project that could host the list. I dropped a note to the
 postmaster @ vger.kernel.org just in case.

vger.kernel.org is the only viable alternative i think

 Or we could host it ourselves, we do not have a huge volume... we just
 want some stable and well backed up mailman thing. Though self hosting
 is a pain too ..

ugh, please no :)
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Q: alternative hosting for strace-devel mailing list

[Mike Frysinger]

On 25 Feb 2015 16:37, Philippe Ombredanne wrote:
 On Wed, Feb 25, 2015 at 4:19 PM, Luca Clementi luca.cleme...@gmail.com 
 wrote:
  On Wed, Feb 25, 2015 at 1:06 PM, Philippe Ombredanne pombreda...@nexb.com
  wrote:
  I do not know of any satisfying alternative. Google groups is rather
  crass.
 
  What's the problem with Google groups?
  We use that for a bunch of 'minor' software projects I'm involved with.
 
 Try to get a sane and clean patch through with Google groups
 Try to use the web interface from different countries too...
 It is trying to be too clever on threading and html presentation and
 is MO too much consumer-oriented for doing us any good.
 We need IMHO a no frills vger-type list. no more no less.

it also mucks with the sender sometimes because of Yahoo being stupid with DMARC
http://www.spamresource.com/2014/04/google-groups-rewriting-from-addresses.html
-mike


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] v4l2: use uintmax_t for times

[Mike Frysinger]

There is no guarantee that the backing value for the various time fields
are ints or longs which makes printfs annoying.  Lets cast them to the
uintmax_t type so we can use the j flag and not worry about truncation.

* v4l2.c (v4l2_ioctl): Use j and uintmax_t when printing tv_sec/tv_usec.
---
 v4l2.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/v4l2.c b/v4l2.c
index 88b0532..ae1ebb8 100644
--- a/v4l2.c
+++ b/v4l2.c
@@ -633,9 +633,9 @@ v4l2_ioctl(struct tcb *tcp, const unsigned int code, long 
arg)
b.length, b.bytesused);
printflags(v4l2_buf_flags, b.flags, 
V4L2_BUF_FLAG_???);
if (code == VIDIOC_DQBUF)
-   tprintf(, timestamp = {%lu.%06lu},
-   b.timestamp.tv_sec,
-   b.timestamp.tv_usec);
+   tprintf(, timestamp = {%ju.%06ju},
+   (uintmax_t)b.timestamp.tv_sec,
+   (uintmax_t)b.timestamp.tv_usec);
tprints(, ...);
}
tprints(});
-- 
2.3.0


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] ignore core/compile files

[Mike Frysinger]

Newer autotools includes a compile helper script.

* .gitignore: Add /compile and core.
---
 .gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.gitignore b/.gitignore
index 770bba7..13b6afc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,6 +5,7 @@
 .version
 .*.swp
 *.gdb
+core
 .gdbinit
 .gdb_history
 
@@ -16,6 +17,7 @@ Makefile.in
 
 /aclocal.m4
 /autom4te.cache
+/compile
 /config.guess
 /config.h
 /config.h.in
-- 
2.3.0


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

[PATCH] ia64: fix up builds after 16bit uuid support

[Mike Frysinger]

The ia64 port pulls in the i386 syscall table so it can decode 32bit
apps, so we need to enable the 16bit uid parsers for it.

* defs.h (NEED_UID16_PARSERS): Define to 1 for IA64.
* linux/ia64/syscallent.h: Undefine sys_stime to avoid redefine warnings.
---
 defs.h  | 1 +
 linux/ia64/syscallent.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/defs.h b/defs.h
index 85c79f5..adbc006 100644
--- a/defs.h
+++ b/defs.h
@@ -348,6 +348,7 @@ extern const struct xlat whence_codes[];
 
 #if defined(ARM) || defined(AARCH64) \
  || defined(I386) || defined(X32) || defined(X86_64) \
+ || defined(IA64) \
  || defined(BFIN) \
  || defined(M68K) \
  || defined(MICROBLAZE) \
diff --git a/linux/ia64/syscallent.h b/linux/ia64/syscallent.h
index 9b23fcd..d44071f 100644
--- a/linux/ia64/syscallent.h
+++ b/linux/ia64/syscallent.h
@@ -26,6 +26,9 @@
  * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+/* Undo any defines that an earlier dummy.h inclusion setup.  */
+#undef sys_stime
+
 /*
  * IA-32 syscalls that have pointer arguments which are incompatible
  * with 64-bit layout get redirected to printargs.
-- 
2.3.0


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Warning after running bootstrap

[Mike Frysinger]

On 21 Feb 2015 19:23, Alangi Derick wrote:
  I just did a pull on the master branch. I pulled the latest working
 copy of Strace and i ran the bootstrap file(./bootstrap). I found out that
 there where some warnings and i don't understand what it means. Can anyone
 help me with the meaning and how it can be solved?

you didn't post any warnings ...
-mike


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel

Re: Building Source Strace Source Codes

[Mike Frysinger]

On 19 Feb 2015 20:26, Alangi Derick wrote:
  I found out something when i built the latest version of Strace. I
 notice that when i build the source, the object files are mixed with the
 source codes them selves(.c files) but i thought of an idea that:
 - When the source codes are built using: make, there should be a separate
 folder that the object files can be generated and kept in so as to keep the
 directory clean and not mixed with object files and source codes. This will
 lead to ease in search of files.
  That is an idea i had in mind but if there is a special reason for
 allowing the object files in the same directory as the source files, i will
 like to know because i am planning on working on the build so as the object
 files can be stored in a folder called:
 strace_build which contains all the .o(binary) files generated by running
 make.

you can already do this if you want:
 make distclean
 mkdir build
 cd build
 ../configure
 make -j
 ./strace

each method has advantages
-mike


signature.asc
Description: Digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel