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, because
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 o
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
> > reverted, because rep
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 pe
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 wit
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 etc
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 t
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 cou
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 p
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
> r
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 curious
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 f
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 fo
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 stand
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-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To un
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 an
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, as
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
wrapper
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 prohib
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. ptrace
29 matches
Mail list logo
