Hi all,
the recent changes for ptrace(2) to allow thread debugging had the
unintentional side effect of breaking single stepping in the existing
GDB in some cases. I have one binary here where setting a conditional
break point consistently results in ptrace(2) returning ESRCH.
Problem is that
I've been looking at some quite weird behaviour with mmapped files on ffs.
I want to concentrate on something else for a while, so here's a brain
dump of what I've been struggling with recently, in case it rings a bell
for someone or they even know the solution.
Background:
The shmif
The only difference between the two programs is this:
#if 1
read(fd, buf, BUFSIZE);
bmem = (void *)buf;
#else
busmem = mmap(NULL, sb.st_size, PROT_READ, MAP_FILE|MAP_SHARED, fd,
0);
if (busmem == MAP_FAILED)
err(1, mmap);
bmem =
On Tue, Aug 17, 2010 at 12:12:31PM -0400, Paul Koning wrote:
If the goal is to allow older GDB binaries to continue to run, that's
a different matter. But in fact such binaries don't function in a
useful way except with single-threaded applications, so keeping them
running doesn't seem like a
On Tue, Aug 17, 2010 at 01:14:50PM -0400, Paul Koning wrote:
I don't understand the reference to chroot. How does that relate to PT_STEP?
Get the sets from NetBSD 5.0, extract them in a directory, chroot to
that. Try gdb -- broken.
Joerg
On Tue, Aug 17, 2010 at 17:07:14 +0200, Joerg Sonnenberger wrote:
Problem is that historically PT_STEP's data argument was ignored and the
in-tree gdb has one case where it provides a signal number as data.
What is the best solution? From looking at all the cases, I think the
only sane
On Aug 17, 2010, at 12:45 PM, Joerg Sonnenberger wrote:
On Tue, Aug 17, 2010 at 12:12:31PM -0400, Paul Koning wrote:
If the goal is to allow older GDB binaries to continue to run, that's
a different matter. But in fact such binaries don't function in a
useful way except with single-threaded
Can't you just version it? Rename existing PT_STEP to PT_OSTEP or
something, define PT_STEP with the new value (instead of introducing
new PT_* name)?
That works for ABI compatability but not API compatability.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against
On Aug 17, 2010, at 2:15 PM, Joerg Sonnenberger wrote:
On Tue, Aug 17, 2010 at 10:10:17PM +0400, Valeriy E. Ushakov wrote:
On Tue, Aug 17, 2010 at 17:07:14 +0200, Joerg Sonnenberger wrote:
Problem is that historically PT_STEP's data argument was ignored and the
in-tree gdb has one case
On Tue, 17 Aug 2010, Paul Koning wrote:
On Aug 17, 2010, at 2:15 PM, Joerg Sonnenberger wrote:
On Tue, Aug 17, 2010 at 10:10:17PM +0400, Valeriy E. Ushakov wrote:
On Tue, Aug 17, 2010 at 17:07:14 +0200, Joerg Sonnenberger wrote:
Problem is that historically PT_STEP's data argument was
On Aug 17, 2010, at 11:07 AM, Joerg Sonnenberger wrote:
Hi all,
the recent changes for ptrace(2) to allow thread debugging had the
unintentional side effect of breaking single stepping in the existing
GDB in some cases. I have one binary here where setting a conditional
break point
On Aug 17, 2010, at 4:46 PM, Eduardo Horvath wrote:
On Tue, 17 Aug 2010, Paul Koning wrote:
On Aug 17, 2010, at 2:15 PM, Joerg Sonnenberger wrote:
On Tue, Aug 17, 2010 at 10:10:17PM +0400, Valeriy E. Ushakov wrote:
On Tue, Aug 17, 2010 at 17:07:14 +0200, Joerg Sonnenberger wrote:
On Aug 17, 2010, at 4:55 PM, Joerg Sonnenberger wrote:
On Tue, Aug 17, 2010 at 03:21:17PM -0400, Paul Koning wrote:
Let me suggest a simpler solution.
Fine with me :)
The problem is in the meaning of the data argument in PT_STEP.
Yes.
The others (in particular PT_CONTINUE) use
On Tue, Aug 17, 2010 at 05:04:14PM -0400, Paul Koning wrote:
Yes, one could implement a completely new set of ptrace-like functions
along the lines you describe. It would have to be a new syscall
because what you describe isn't ptrace, though it looks a bit like it.
I don't see why it is not
On Aug 17, 2010, at 5:19 PM, Joerg Sonnenberger wrote:
On Tue, Aug 17, 2010 at 05:04:14PM -0400, Paul Koning wrote:
Yes, one could implement a completely new set of ptrace-like functions
along the lines you describe. It would have to be a new syscall
because what you describe isn't ptrace,
On Aug 17, 2010, at 5:33 PM, Eduardo Horvath wrote:
On Tue, 17 Aug 2010, Paul Koning wrote:
(3) if the process only has one thread ignore he argument.
That means the semantics of ptrace can change out from under the program
using it. If it passes an argument to PT_STEP because there
16 matches
Mail list logo
