Re: Possibly a bug in glibc around the getrandom(2) implementation.

[Marcin Mielniczuk <marmistrz dot dev at zoho dot eu>]

You're right I mixed it all up. My bad.

I fixed that to use PTRACE_PEEKUSER for RSP and now the RSP matches with
what gdb reports. This means the big getrandom buffers are all ok, first
is allocated somewhere else (static?)

    getrandom request: 0x00007f5e97a659a0 0x00007f5e97a659b8
    rsp is 0x7ffcd86af260
    getrandom request: 0x00007ffcd86ad5b0 0x00007ffcd86adf70
    rsp is 0x7ffcd86acdd8
    getrandom request: 0x00007ffcd86ace40 0x00007ffcd86ad800
    rsp is 0x7ffcd86acd60

I slightly modified the code to show buf, buf+len instead of buf, len.

But if I omit the poke for the second getrandom request, the program
completes successfully... The buffer is ok, fully contained in the stack:

     7ffcd8690000-7ffcd86b1000 rw-p 00000000 00:00 0                          [stack]

I double receive all messages from the mailing list. Is this the
expected behavior? I'm subscribed.


On 17.07.2017 20:52, Florian Weimer wrote:
> * Marcin Mielniczuk:
>
> > I decided to start printing the rsp to the stdout, in the following way:
> >                       register unsigned long rsp asm("rsp");
> >                       printf("rsp is %p\n", (void*) rsp);
> Doesn't this print the %rsp value in the tracing program, and not the
> traced program?