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