From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by sourceware.org (Postfix) with ESMTPS id 7B56F3858023 for ; Thu, 7 Jan 2021 21:50:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7B56F3858023 Received: by mail-lf1-x134.google.com with SMTP id o13so18212806lfr.3 for ; Thu, 07 Jan 2021 13:50:03 -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=L4nXB2EPk7GN8qUdTHRObb0ssV6tT/dfXpGNGyk6fA4=; b=BNXZ4QLkz9jjIFoewYIsa4PgEpNHwfZTXxVVUVLUU5jTvSu/qpSakpDl9/Wk32mwiO zKr2XTj8WjkULcvLQGHsQgOcey4XL0CISu9Mjzg5Pj0pJ1Yc86R4A1UoGbQqfx3WQkaR j3e8N/M9A0vzviEJbty3m159f9lalCH389erh7mUo7dpALrkukpU8AA8R3udvQWxPS4p 7RJS0WTIqVzY7Q/gt9+gOJAKjiqKuQAjngIMfSw1S/aH7Skmh0DLvV467JYYcudJ/uqw OuiPs2I2F842LO5OH6WmoaAPrs1el5YUUIEo/8xPKTVRDSmMP7TTLA7lhNCkAXLORnxH y9WA== X-Gm-Message-State: AOAM533DnrsUwS/Jk2q88qVW7RT5f1h0oxCvWA8rR8WxiCzkMmkOtom8 g5lFpIaKwRMxJOhRYKppHkgry+JZEhMeWslNyKGfK0HSW/8P4A== X-Google-Smtp-Source: ABdhPJyzjiOKTxTrYmvXNyrm0qKYnk8XMjFj6qE6kFDIQYNx7ny7TtT3dlDpEihAZvp0ixiurKZtWlX0x4eaJfFz1D0= X-Received: by 2002:a05:6512:717:: with SMTP id b23mr297278lfs.488.1610056201502; Thu, 07 Jan 2021 13:50:01 -0800 (PST) MIME-Version: 1.0 References: <87eeiwv41k.fsf@tromey.com> In-Reply-To: <87eeiwv41k.fsf@tromey.com> From: Walt Drummond Date: Thu, 7 Jan 2021 13:49:50 -0800 Message-ID: Subject: Re: AMD64_LINUX_frame_size To: Tom Tromey Cc: Walt Drummond via Gdb Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: Thu, 07 Jan 2021 21:50:05 -0000 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? On Thu, Jan 7, 2021 at 1:19 PM Tom Tromey wrote: > > >>>>> "Walt" == Walt Drummond via Gdb writes: > > Walt> After looking at this further, I think I understand AMD64_LINUX_frame_size > Walt> and why it differs from the size of the kernel's rt_sigframe (differences > Walt> between glibc's and the kernels' definition of sigset_t), but I don't > Walt> understand how GDB arrived at 512 for AMD_LINUX_xstate. The kernel's math > Walt> frame, which also contains the extended state information, is 840 bytes. I > Walt> feel I must be missing something. Any pointers? > > I don't really know, but from a quick look at this code, it seems like > this is only used by the process record code, and furthermore only like: > > if (record_full_arch_list_add_mem (rsp, AMD64_LINUX_redzone > + AMD64_LINUX_xstate > + AMD64_LINUX_frame_size)) > return -1; > > These are defined as: > > #define AMD64_LINUX_redzone 128 > #define AMD64_LINUX_xstate 512 > #define AMD64_LINUX_frame_size 560 > > which adds up to 1200, which maybe is also wrong (dunno), but at least > is larger and maybe (also dunno) harmless in this context. > > Tom