AMD64_LINUX_frame_size

[Walt Drummond]

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 <tom@tromey.com> wrote:
>
> >>>>> "Walt" == Walt Drummond via Gdb <gdb@sourceware.org> 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