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 hist
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 rum
> 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");
>
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 lik
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 cons
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 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 where it provides a signal number as data.
> >
> > Wh
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-th
> 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 on
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
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 cons
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 wr
On Tue Aug 17 2010 at 19:06:38 +0300, Antti Kantee wrote:
> Usually after the bus has seen one generation (i.e. the pages have been
> faulted in to all processes) there are no further problems. However,
> causing (read) faults from a 3rd party process not involved with the
> test may trigger the p
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 positive value of data to
> mean signum, and negative to mean LWP
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_CONTIN
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 no
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 pt
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 are two threads,
> and one thread exits before the p
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 becaus
21 matches
Mail list logo
