From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 6BBC63858D37 for ; Sun, 26 Dec 2021 06:01:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6BBC63858D37 Received: by mail-ed1-x52f.google.com with SMTP id bm14so48744123edb.5 for ; Sat, 25 Dec 2021 22:01:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sx91YT/cDSFu9/uwcH12s3rtGKzpxtr2RwgNSYxxs6g=; b=RTPXwGGN9CxT7O90E2CipPUT4QcAE+kyRDjQn/o0sFMofntI4/7vqM4swzH6z0lJEd 3s8qy6qeg+9goF/X+pMGDRuIbkOLVyH3+gozNEEt88Cx7CfVnvl6ISQUsBv6waZ4IdZk Aqp7IDbBoedcBpPcqR+Z1gHX6PHjjfWC5N4pYsOqvdHdICvsUeq647Btec6C91UzU/cW emYFjDVDzlWdhsyWFdRhN7lTp6XAl3ZQK1h8A/Ga1AsK4Da1wWtKtUpdNXEVELUlKxDl W9TK842/rFOkwGQpPnmZt03OabihtDGnU7sLbUJfjUOGp5ePlbqBTIXZt17iMMcvgfxw OBrA== X-Gm-Message-State: AOAM533FZEXhohSYIRsSh91Q7Ou3knOyicnkQiwOLJamSqZgteZAK4zj yzq01UEeyylRuAz1kF88wphJEqyWNxl3LFqnhrvPSFMRvos= X-Google-Smtp-Source: ABdhPJwLca8DYnD0y6Lj7THK6lV8tvC0tbcwCQIFYyXoSwGAMBJzxcLptZ8KsxWiB49NvTA4xfoB/aYCY6gPWDgoTlA= X-Received: by 2002:a05:6402:60c:: with SMTP id n12mr11757860edv.17.1640498486789; Sat, 25 Dec 2021 22:01:26 -0800 (PST) MIME-Version: 1.0 From: aldelaro5 Date: Sun, 26 Dec 2021 01:01:15 -0500 Message-ID: Subject: Asking for the best way to implement a way to trigger watchpoint without changes To: gdb@sourceware.org X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2021 06:01:30 -0000 Hi. I have come into a situation where I need to be able to have watchpoint triggers even if the underlying address has not changed. My particular situation is the following: I am looking into reversing engineering console games such as GBA games which have emulators like mgba that implements a GDB stub which implements the different types of Z packets so I can ask to have write only watchpoint (for this particular case, I don't want read/write, only write). I want to be able to use a GDB frontend like the one ghidra (reverse engineering tool) provides, meaning it is preferable if what I want to do involves using regular GDB commands. There are 2 problems that the current implementation of watchpoint causes me: 1. Most of the time, I actually care that a write happened regardless if the value changed. Let's say I care that something tried to refresh it. As a reverse engineer, knowing this can be helpful in a lot of cases. 2. Console emulators like these usually implement a feature to restore the state of the emulation (memory, CPU, etc...) which means that the following can happen: I save a state, then let the inferior trigger a watchpoint, resume and then for whatever reason, I want to go back so I restore the state, trigger the watchpoint again which GDB will see, but it will proceed to ignore it because for GDB, it's as if the value never changed between the time it triggered. It is possible to workaround this by manually sending ctrl+c which will force GDB to reread the value on the next continue, but it's not ideal. The way I see it is there would be 2 ways to solve the second problem, but one of them solves both and it is to optionally have GDB trigger a watchpoint regardless if it changed or not. The other solution is to somehow have the stub inform GDB that things changed, but the only way I could find was to send a stop reply with the information...except that it still pauses the inferior so really it doesn't help me since I can send ctrl + c anyway. Which is why I am seriously considering implementing the watchpoint part because as far as I could research, GDB cannot do this currently. I even looked into the events part of the Python api and although it is possible to register a stop event handler, such handler will not be called until GDB decides to actually stop after verifying that the value has changed; so it doesn't help me. What seems interesting however is the only thing preventing me to do this is an if statement in bpstat_check_watchpoint from breakpoint.c meaning as someone who is relatively new to the internal structure to the project (I had to debug GDB itself recently to uncover a nexti issue), this is something I could try to implement. My question is simple: what would be the best way to do this? should I add a config option? a command line argument? I am open to hear suggestions on this. To note, there is actually a bug report filed on this (bug 19221), but it seemed to not have any activity on it for years.