Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Guinevere Larsen via Gdb <gdb@sourceware.org>
To: Navin P <navinp0304@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Error record and replay target doesn't support syscall number 435
Date: Mon, 13 May 2024 10:10:22 -0300	[thread overview]
Message-ID: <b038c80a-1924-48f3-92c2-0dea1108d48f@redhat.com> (raw)
In-Reply-To: <CALO2TqL6Jp0cgtcoaGRPi6PQODsY4U86ZTohzHvCoshFm++JUw@mail.gmail.com>

On 5/13/24 08:06, Navin P wrote:
> Hi,
Hi! :)
>
> On Fri, May 10, 2024 at 7:29 PM Guinevere Larsen <blarsen@redhat.com> wrote:
>> On 5/10/24 05:07, Navin P via Gdb wrote:
>>> Hi,
>>>        I tried to record a program calling C++ threads and then did a
>>> break on main , then record and continue it throws the error message
>>> "record and replay target doesn't support syscall number 435" . What
>>> should I do to support syscall number 435 ?
>> Hi!
>>
>> I can't answer everything, since I'm not too familiar with syscalls
>> specifically, but I'll do my best!
>>
>> My first road bump with this is that we record that a clone has
>> happened, but we can only record the process that GDB is following
>> (parent or child, depending on follow-fork-mode). This is
>> counter-intuitive to me, since I would have expected the full inferior
>> to be replayed.
> To get this working you need minimum changes of current_inferior to
> for each inferior in all_inferiors() and execute that function for
> each inferior.
> return values have to be captured in a list. Similarly for each return value
> you have to perform the actions in a loop.

There is an extra complication, the recording subsystem was added before 
GDB could handle multiple inferiors, so it works on the assumption that 
you only need one global history. Meaning if we did record for all 
inferiors or all processes, the history would be mangled, jumping from 
one inferior to the next. It is already a problem in handling 
multi-threaded inferiors, so a proper fix would require having a 
per-thread history, and possibly some way to serialize the execution.

I added the explanation more as a motivator to why I think we should 
warn the user of the counter-intuitive behavior, at least in the 
documentation.

> It is going to definitely slow down execution by orders of magnitude.
Absolutely! I'm almost wondering if we should try to spawn a recording 
thread per process or thread, to at least make multi-threaded recording 
not worse. But that is far in the future, unrelated to this change
> Does any free software or paid versions of software capture segfault in
> fork on parent(P) and child (C) or something more nested than this?
> P->C->P
I'm unaware of any, but also GDB is the only debugger I ever really 
used, so there may be something out there.
> int main(){
> int i=0;
> int *p=&i;
> if(fork()==0){
>      p=nullptr;
>      if(fork()!=0){
>          int z=*p+5; //segfault
>      } else {
>          int x;
>          wait(&x);
>      }
> } else {
>     int x;
>     wait(&x);
> }
> }
>
>
>
>>> I was thinking of adding amd64_sys_clone3 = 435 to amd64-linux-tdep.h
>>> In amd64-linux-tdep.c add  case amd64_sys_clone3: return gdb_sys_clone3;
>>> In linux-record.h gdb_sys_clone3=541 in enum gdb_syscall
>> these 3 changes make sense to me
>>> In linux-record.c case gdb_sys_clone3=break;
>>>
>>>
> I've created a pull request and verified that in record mode it starts
> and executes
> the threads but it doesn't break on the segfault in the thread.
>
> https://github.com/bminor/binutils-gdb/pull/11
I can take a look at it as is, but that github repo is just an 
unofficial mirror. The proper way to submit changes is to send your 
patch to gdb-patches@sourceware.org, and we'll do proper review through 
email.

-- 
Cheers,
Guinevere Larsen
She/Her/Hers

>
>
>> --
>> Cheers,
>> Guinevere Larsen
>> She/Her/Hers
>>
>>> Below is gdb log and after that is source code
>>>
>>> gdb ./a.out
>>> GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
>>> Copyright (C) 2022 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> Type "show copying" and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <https://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>>       <http://www.gnu.org/software/gdb/documentation/>.
>>>
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from ./a.out...
>>> (gdb) b main
>>> Breakpoint 1 at 0x134b: file race1.cpp, line 30.
>>> (gdb) r
>>> Starting program: /home/navin/cpp/a.out
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>>
>>> Breakpoint 1, main () at race1.cpp:30
>>> 30 int main(){
>>> (gdb) record full
>>> (gdb) c
>>> Continuing.
>>> Process record and replay target doesn't support syscall number 435
>>> Process record: failed to record execution log.
>>>
>>> Program stopped.
>>> clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:60
>>> 60 ../sysdeps/unix/sysv/linux/x86_64/clone3.S: No such file or directory.
>>> (gdb) shell uname -a
>>> Linux Navin-acer-5740 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14
>>> 13:30:08 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
>>> (gdb) shell cat /etc/lsb-release
>>> DISTRIB_ID=LinuxMint
>>> DISTRIB_RELEASE=21.2
>>> DISTRIB_CODENAME=victoria
>>> DISTRIB_DESCRIPTION="Linux Mint 21.2 Victoria"
>>> (gdb)
>>>
>>>
>>> Source Code
>>>
>>> #include<bits/stdc++.h>
>>> #include<thread>
>>> using namespace std;
>>>
>>> int g=0;
>>> int *p=&g;
>>> bool run=true;
>>>
>>> void t1()
>>> {
>>> while(run)
>>> {
>>> g++;
>>> if(g==16)
>>>      p=nullptr;
>>>
>>> }
>>> }
>>>
>>> void t2()
>>> {
>>> int z;
>>> while(run)
>>> {
>>> g--;
>>> z=*p+1;
>>> }
>>> }
>>>
>>> int main(){
>>> thread x1{t1};
>>> thread x2{t2};
>>> sleep(5);
>>> run=false;
>>> x1.join();
>>> x2.join();
>>> cout <<g<<endl;
>>> }
>>>
>>>
>>>
>>> Regards,
>>> Navin
>>>


  reply	other threads:[~2024-05-13 13:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-10  8:07 Navin P via Gdb
2024-05-10 13:59 ` Guinevere Larsen via Gdb
2024-05-13 11:06   ` Navin P via Gdb
2024-05-13 13:10     ` Guinevere Larsen via Gdb [this message]
     [not found]       ` <CALO2TqL2nyornGqMhSHo8gKKPgK=S-hP+UBBf8q+XvxMoj2BAQ@mail.gmail.com>
2024-05-13 18:17         ` Guinevere Larsen via Gdb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b038c80a-1924-48f3-92c2-0dea1108d48f@redhat.com \
    --to=gdb@sourceware.org \
    --cc=blarsen@redhat.com \
    --cc=navinp0304@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox