On Monday, August 29, 2016 10:10:35 PM Konstantin Belousov wrote:
> On Mon, Aug 29, 2016 at 09:16:29PM +0300, Andrey Chernov wrote:
> > Previous text is documented everywhere and describing usual good
> > practice, so it should remains in place, in that means r304928 should be
> > reverted,
On 29.08.2016 22:10, Konstantin Belousov wrote:
> On Mon, Aug 29, 2016 at 09:16:29PM +0300, Andrey Chernov wrote:
>> Previous text is documented everywhere and describing usual good
>> practice, so it should remains in place, in that means r304928 should be
>> reverted, because replace proper way
On Mon, Aug 29, 2016 at 2:10 PM, Konstantin Belousov
wrote:
> On Mon, Aug 29, 2016 at 09:16:29PM +0300, Andrey Chernov wrote:
> > Previous text is documented everywhere and describing usual good
> > practice, so it should remains in place, in that means r304928 should be
> >
On Mon, Aug 29, 2016 at 09:16:29PM +0300, Andrey Chernov wrote:
> Previous text is documented everywhere and describing usual good
> practice, so it should remains in place, in that means r304928 should be
> reverted, because replace proper way of doing things with obsoleted
> feature description.
On 29.08.2016 21:16, Andrey Chernov wrote:
> On 29.08.2016 21:04, Konstantin Belousov wrote:
>> On Mon, Aug 29, 2016 at 08:46:47PM +0300, Andrey Chernov wrote:
>>> Either we implement this wrapper or left all things as is, we need to
>>> document internal errno clearing additionally, to not make
On 29.08.2016 21:04, Konstantin Belousov wrote:
> On Mon, Aug 29, 2016 at 08:46:47PM +0300, Andrey Chernov wrote:
>> Either we implement this wrapper or left all things as is, we need to
>> document internal errno clearing additionally, to not make people wonder
>> why errno becomes 0, probably
On Mon, Aug 29, 2016 at 09:51:50AM -0700, John Baldwin wrote:
> On Monday, August 29, 2016 09:58:13 AM Konstantin Belousov wrote:
> > I dug into the ptrace(2) consumers, I found a lot of things using
> > it which I would not expect to use, besides usual suspects of gdb
> > lldb libunwind reptyr
On 29.08.2016 19:51, John Baldwin wrote:
>> int
>> ptrace(int request, pid_t pid, caddr_t addr, int data)
>> {
>>
>> errno = 0;
>> return (__sys_ptrace(request, pid, addr, data));
>> }
>
> Certainly I think having a C wrapper like this makes more sense than
> doing it all in assembly N
On Monday, August 29, 2016 09:58:13 AM Konstantin Belousov wrote:
> On Sun, Aug 28, 2016 at 04:09:51PM -0700, John Baldwin wrote:
> > OTOH, given that we explicitly documented it as not being true, I suspect
> > any applications that are using ptrace() are going off the documentation,
> > not
> >
On 29.08.2016 18:34, Konstantin Belousov wrote:
> On Mon, Aug 29, 2016 at 06:05:50PM +0300, Andrey Chernov wrote:
>> No surprise since they all share the same initial implementation. You
>> can add NetBSD and OpenBSD too. Errno clearing as undocumented side
>> effect is not what we need, and every
On Mon, Aug 29, 2016 at 06:05:50PM +0300, Andrey Chernov wrote:
> No surprise since they all share the same initial implementation. You
> can add NetBSD and OpenBSD too. Errno clearing as undocumented side
> effect is not what we need, and every system documents that user must
> clear errno.
Of
On 29.08.2016 10:07, Konstantin Belousov wrote:
> On Mon, Aug 29, 2016 at 09:58:13AM +0300, Konstantin Belousov wrote:
>> On Sun, Aug 28, 2016 at 04:09:51PM -0700, John Baldwin wrote:
>>> OTOH, given that we explicitly documented it as not being true, I suspect
>>> any applications that are using
On Mon, Aug 29, 2016 at 09:58:13AM +0300, Konstantin Belousov wrote:
> On Sun, Aug 28, 2016 at 04:09:51PM -0700, John Baldwin wrote:
> > OTOH, given that we explicitly documented it as not being true, I suspect
> > any applications that are using ptrace() are going off the documentation,
> > not
On Sun, Aug 28, 2016 at 04:09:51PM -0700, John Baldwin wrote:
> OTOH, given that we explicitly documented it as not being true, I suspect
> any applications that are using ptrace() are going off the documentation, not
> the implementation artifact. Note that Linux's ptrace() documents the same
>
On Sunday, August 28, 2016 04:52:10 AM Konstantin Belousov wrote:
> On Sun, Aug 28, 2016 at 04:25:46AM +0300, Andrey Chernov wrote:
> > On 28.08.2016 4:15, Konstantin Belousov wrote:
> > >> POSIX: "No function in this volume of POSIX.1-2008 shall set errno to
> > >> zero."
> > > I am quite
On 28.08.2016 8:28, Bruce Evans wrote:
>> How hard it will be to bring ptrace() to what C99 expects? Perhaps now
>> time is suited well to change some obsoleted things.
>
> This should be safe to change, since portable applications like gdb can't
> assume that the implemementation clobbers errno
On Sun, 28 Aug 2016, Andrey Chernov wrote:
On 28.08.2016 4:52, Konstantin Belousov wrote:
POSIX: "For each thread of a process, the value of errno shall not be
affected by function calls or assignments to errno by other threads."
And ? What should the citation add new to the substance
of the
On 28.08.2016 5:33, Andrey Chernov wrote:
> "conforming implementation may have extensions (including additional
> library functions), provided they do not alter the behavior of any
> strictly conforming program.3)"
>
> ptrace() is extension (additional library function) so can't set errno
> to 0
On 28.08.2016 4:52, Konstantin Belousov wrote:
POSIX: "For each thread of a process, the value of errno shall not be
affected by function calls or assignments to errno by other threads."
>>> And ? What should the citation add new to the substance
>>> of the code change ?
>>
>> This is
On Sun, Aug 28, 2016 at 04:25:46AM +0300, Andrey Chernov wrote:
> On 28.08.2016 4:15, Konstantin Belousov wrote:
> >> POSIX: "No function in this volume of POSIX.1-2008 shall set errno to
> >> zero."
> > I am quite curious where ptrace(2) is defined by POSIX.
>
> POSIX just repeats C99 statement
On 28.08.2016 4:37, Andrey Chernov wrote:
> On 28.08.2016 4:25, Andrey Chernov wrote:
>>> Point me to a single line in C99 which mentions ptrace().
>
> Already done: ptrace == "any library function".
To elaborate it more, C99 does not have finite list of library
functions, but it says about
On 28.08.2016 4:25, Andrey Chernov wrote:
>> Point me to a single line in C99 which mentions ptrace().
Already done: ptrace == "any library function".
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To
On 28.08.2016 4:15, Konstantin Belousov wrote:
>> POSIX: "No function in this volume of POSIX.1-2008 shall set errno to zero."
> I am quite curious where ptrace(2) is defined by POSIX.
POSIX just repeats C99 statement for its own functions, supporting this
rule too, but C99 rule is more general
On 28.08.2016 4:04, Andrey Chernov wrote:
> On 28.08.2016 3:56, Konstantin Belousov wrote:
>> On Sun, Aug 28, 2016 at 03:38:10AM +0300, Andrey Chernov wrote:
>>> On 28.08.2016 2:03, Konstantin Belousov wrote:
Since ptrace(2) syscall can return -1 for non-error situations, libc
On Sun, Aug 28, 2016 at 03:50:04AM +0300, Andrey Chernov wrote:
> On 28.08.2016 3:38, Andrey Chernov wrote:
> > On 28.08.2016 2:03, Konstantin Belousov wrote:
> >> Since ptrace(2) syscall can return -1 for non-error situations, libc
> >> wrappers set errno to 0 before performing the syscall,
On 28.08.2016 3:56, Konstantin Belousov wrote:
> On Sun, Aug 28, 2016 at 03:38:10AM +0300, Andrey Chernov wrote:
>> On 28.08.2016 2:03, Konstantin Belousov wrote:
>>> Since ptrace(2) syscall can return -1 for non-error situations, libc
>>> wrappers set errno to 0 before performing the syscall,
On Sun, Aug 28, 2016 at 03:38:10AM +0300, Andrey Chernov wrote:
> On 28.08.2016 2:03, Konstantin Belousov wrote:
> > Since ptrace(2) syscall can return -1 for non-error situations, libc
> > wrappers set errno to 0 before performing the syscall, as the service
> > to the caller.
>
> Both C99
On 28.08.2016 3:38, Andrey Chernov wrote:
> On 28.08.2016 2:03, Konstantin Belousov wrote:
>> Since ptrace(2) syscall can return -1 for non-error situations, libc
>> wrappers set errno to 0 before performing the syscall, as the service
>> to the caller.
>
> Both C99 and POSIX directly
On 28.08.2016 2:03, Konstantin Belousov wrote:
> Since ptrace(2) syscall can return -1 for non-error situations, libc
> wrappers set errno to 0 before performing the syscall, as the service
> to the caller.
Both C99 and POSIX directly prohibits any standard function to set errno
to 0.
Author: kib
Date: Sat Aug 27 23:03:23 2016
New Revision: 304928
URL: https://svnweb.freebsd.org/changeset/base/304928
Log:
Do not obliterate errno value in the main thread during ptrace(2) call on x86.
Since ptrace(2) syscall can return -1 for non-error situations, libc
wrappers set
30 matches
Mail list logo