From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 10C2938582B7 for ; Wed, 5 Oct 2022 16:54:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 10C2938582B7 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4MjLJ86KHpz405V; Wed, 5 Oct 2022 16:54:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MjLJ85TH3z3tRr; Wed, 5 Oct 2022 16:54:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664988840; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vSTHMwYY251Nh6EF0oTc5nOpbWgEUnS41W4LQIe3raY=; b=Br6TRKeoe7LzWX9JojX51z51KTSOnSdIewUM6a7t0iXo69u5C/4gsoehEYywugDbMowkBZ STq8SZQ9MM2Xz7tCSzJIcDRVA6Um/6jStdkbZRLLZmcmndHJSC2KdCYPLaQAqx1IY765ol uI177I+TWzpY0gGWL60NWhubtL0fKN3w5DZ90d6GoMv8XCc7xoEOpDpxqNlqdWbyoHvC10 fotKQTkQACwijWu13SSCgLyniNcsuIwYCSn8FmgxNitgEQTGNMkmZ6Hvm1vi2zM5uVZH86 jyHTES6NmiRkZK7mNyVbI5Obq9qHhKZndPqCcOcQ0jVKTTdv1AZa4cclTdM+bw== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MjLJ82R2kzTTM; Wed, 5 Oct 2022 16:54:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Wed, 5 Oct 2022 09:53:59 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 Subject: Re: Context switch during stepping causes weird behavior Content-Language: en-US To: Adrian Oltean , "gdb@sourceware.org" References: From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664988840; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=vSTHMwYY251Nh6EF0oTc5nOpbWgEUnS41W4LQIe3raY=; b=pFEd+QfGniBITkWErdhyCcOfRJfWDt9z+HZKficvyy1s6mYgYzQINiqpzrG6kI6fsnbaP+ SaeMD//9qNhMLiB2+3dBt8ZUvQPk6p/KL8r2+bwnZf5K1qxALVHYCYPn7ejKrqkoPYPIny jeoUW3VTirKmIZ7G+dHsSZUUWCyDoPMD6lUHT+hT5QLcWX0ye+kBk+VkvEA44U8LC91sJo /OMcD3aFmQmDliXjoLBkqjn/0DVQMYTKMnHSCms7bTimW6sWQIhOpS/Tp3B5rGdluV/t4h NMnkn+8sK339skBBhO4DUYI3PSX9VpMRV/90gXLvR8XytWhgOMQL6PhcZAsrkQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664988840; a=rsa-sha256; cv=none; b=xIt9pP8oVRKRxhfnRyXw81pMEj03VezH9rkeWyW19x715yQJxdUxLlNGVEObyXff2ctdVv 7/vG2pc432ngUFJCKei3miautH9OrqLC21pmSTqABCFflCWZQZFlljCbNnLsYER1PVKGsd vZFkMTKNVh69jq1YoL/RH/o/KaFoqX7YfbZEcJfsdy7vbmlIbo2xeaHGSKKGKq1uX/E4WW jObfJXFJz7rswWZJksgEaR4OoWTvy+v1jX5yuwaDBp9BhPzD91SW+P9fATuKeSyaBoPOww QloKQRNcgeCwQX8DXfaHeVntnUwOzZx5rTtjsjOzwiKzR1+vKNEdEZapmjDN4g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 10/4/22 11:48 PM, Adrian Oltean wrote: > Hi John, > > Thanks for sharing your experience. I'm also planning to recommend our customers to use breakpoints instead of actual step operations. However, I still don't like the uncontrollable GDB when stepping and kernel thread gets moved. In your case, I see a friendlier behavior - at least stepping stops at some point, even though not reaching the expected code section. This would be my goal as well. Maybe someone can suggest how to patch the GDB code in order to suspend the step when GDB detects that stepping thread is actually changed. Unfortunately, I don't have much knowledge about the GDB code and all my attempts failed so far. I wonder if the difference is due to the use of displaced stepping? FreeBSD doesn't support displaced stepping. I don't know off the top of my head if there is a knob to disable displaced stepping. If there is, you might try doing that to see if you get the type of behavior I see where the debugger stops because a step ends up out of bounds. > Thank you, > Adrian > > -----Original Message----- > > Interrupts make single-stepping on bare-metal or OS kernels hard. When doing similar things for debugging FreeBSD's kernel via bare-metal stubs (e.g. in QEMU or in FreeBSD's hypervisor) I generally use 'until' and/or breakpoints instead to work around this rather than using normal stepping. > > On the GDB server side (for the GDB stub in FreeBSD's hypervisor) I've thought about doing odd things like trying to defer interrupts while stepping but there isn't a really good way to deal with that in general. > > (Most of the time when trying to step what happens for me is that I get a reported stop back for a PC in the timer interrupt handler for the local APIC timer interrupt, and then GDB sees that the PC is "out of range" and just stops at that point) > > -- > John Baldwin -- John Baldwin