Re: AMD64_LINUX_frame_size

Walt Drummond via Gdb <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CADCN6nzB1Sn=8200TfpSSbKgBoGJFc35_PtpFd5vfkg7G1uuyw@mail.gmail.com>
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 <[email protected]> wrote:
>
> >>>>> "Walt" == Walt Drummond via Gdb <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.