From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id zk9OFwbK/V8/SAAAWB0awg (envelope-from ) for ; Tue, 12 Jan 2021 11:10:46 -0500 Received: by simark.ca (Postfix, from userid 112) id 4FEFB1EF7E; Tue, 12 Jan 2021 11:10:46 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id DD81D1E940 for ; Tue, 12 Jan 2021 11:10:45 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 48EDA3896836; Tue, 12 Jan 2021 16:10:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 48EDA3896836 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1610467845; bh=BC1N+srrUFZtZrhZ3CgGH2q6H9e397EqLsNZb4/lR+8=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=WJW+VS4aG/2xdkebBArz5NX6zwELn3mqvclJ+/NKCnOb0Bu5XlNr//TXlRQPniLdU bXd/rtPySjVWWBl+pK38kxh1SLmIeHp2QEDLysGprPt0PpcU7mHA3A/z/p2JVGpb34 UnRejYcAYcPDPa9zpM64V6TmV/hl97b1yhfybAhM= Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by sourceware.org (Postfix) with ESMTPS id C55AB3858D29 for ; Tue, 12 Jan 2021 16:10:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C55AB3858D29 Received: by mail-lf1-x12d.google.com with SMTP id o13so4198611lfr.3 for ; Tue, 12 Jan 2021 08:10:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BC1N+srrUFZtZrhZ3CgGH2q6H9e397EqLsNZb4/lR+8=; b=ei9BlFL0kO12cgGznOK5NEKhLGX7CyUgpB+E1upR5FVyJTJK9mNtFYyOo29J709Hu4 7cgSGCCjJus5LgeS0Fb+bKd5S09SqQckZt7VIUWEQBig2JwAhdISoM27Ijk75iSwG2x9 k1IkxZ/32L8r2AoGLjsREkBRavP6F8D2XTFg8A6cBT43f29qlKyPpKLdoDit4kRt4Lqf uP/h+Oj9Jsk8nuAbsNYChr2b60bXXyjkZvjRUWnzmmONclNupOyjr6jVJUcxucZtv84E Ijp+V7qe1u1wb2QxNKOfnmf71mjdKQzb1Wq97yQD9GU9WSqgFerw0n8/by3UdwU3BYJ6 I1Dw== X-Gm-Message-State: AOAM5323DzlGkxNONP24Q3KB88cCd5SPEMh6/CavdU4szGqqbYR38MyL k26iQoPi4mSmZZtNVG3GvptMIAvcPE64lujRx2hA9A== X-Google-Smtp-Source: ABdhPJxQn1bTUGXr2NMdU7UuGb0Xb/ZCBzV5/cPskD9cw14PygI8ZWZrXfB89XGrq45fHtucjl46ZuC+YnUXya8Fke8= X-Received: by 2002:a19:c3cb:: with SMTP id t194mr2356410lff.599.1610467839974; Tue, 12 Jan 2021 08:10:39 -0800 (PST) MIME-Version: 1.0 References: <87eeiwv41k.fsf@tromey.com> <87sg77pxdy.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87sg77pxdy.fsf@oldenburg2.str.redhat.com> Date: Tue, 12 Jan 2021 08:10:29 -0800 Message-ID: Subject: Re: AMD64_LINUX_frame_size To: Florian Weimer Content-Type: text/plain; charset="UTF-8" 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: , From: Walt Drummond via Gdb Reply-To: Walt Drummond Cc: Walt Drummond via Gdb , Tom Tromey Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" I haven't been able to get a handle on this yet. Part of the problem is that I can't construct a test case w/out hitting the "Process record does not support instruction 0xc5 at address 0xblah..." issue, and I haven't found a workaround yet. On Mon, Jan 11, 2021 at 2:43 AM Florian Weimer wrote: > > * Walt Drummond via Gdb: > > > Thanks Tom. My math shows the kernel sizes as > > Redzone 128 > > math frame/xstate 840 > > rt_sigframe 456 > > > > That's a total of 1424 bytes, so maybe GDB is saving less than it should? > > With AVX-512, the kernel size is way larger. > > Do you know for what purpose GDB needs this information? Decoding the > xstate is quite complicated as far as I know. Is it related to > preserving stack contents across signal delivery? > > Thanks, > Florian > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill >