* AMD64_LINUX_frame_size @ 2021-01-04 18:30 Walt Drummond 2021-01-06 16:38 ` AMD64_LINUX_frame_size Walt Drummond 0 siblings, 1 reply; 7+ messages in thread From: Walt Drummond @ 2021-01-04 18:30 UTC (permalink / raw) To: gdb I'm trying to understand the relationship between the AMD64_LINUX_frame_size constant and the kernel's signal stack layout. Is there any documentation or commentary that describes how we got to the current value? Thanks. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AMD64_LINUX_frame_size 2021-01-04 18:30 AMD64_LINUX_frame_size Walt Drummond @ 2021-01-06 16:38 ` Walt Drummond 2021-01-07 21:19 ` AMD64_LINUX_frame_size Tom Tromey 0 siblings, 1 reply; 7+ messages in thread From: Walt Drummond @ 2021-01-06 16:38 UTC (permalink / raw) To: gdb After looking at this further, I think I understand AMD64_LINUX_frame_size and why it differs from the size of the kernel's rt_sigframe (differences between glibc's and the kernels' definition of sigset_t), but I don't understand how GDB arrived at 512 for AMD_LINUX_xstate. The kernel's math frame, which also contains the extended state information, is 840 bytes. I feel I must be missing something. Any pointers? Thanks. On Mon, Jan 4, 2021 at 10:30 AM Walt Drummond <walt@drummond.us> wrote: > I'm trying to understand the relationship between the > AMD64_LINUX_frame_size constant and the kernel's signal stack layout. Is > there any documentation or commentary that describes how we got to the > current value? > > Thanks. > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AMD64_LINUX_frame_size 2021-01-06 16:38 ` AMD64_LINUX_frame_size Walt Drummond @ 2021-01-07 21:19 ` Tom Tromey 2021-01-07 21:49 ` AMD64_LINUX_frame_size Walt Drummond 0 siblings, 1 reply; 7+ messages in thread From: Tom Tromey @ 2021-01-07 21:19 UTC (permalink / raw) To: Walt Drummond via Gdb >>>>> "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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AMD64_LINUX_frame_size 2021-01-07 21:19 ` AMD64_LINUX_frame_size Tom Tromey @ 2021-01-07 21:49 ` Walt Drummond 2021-01-09 20:14 ` AMD64_LINUX_frame_size Tom Tromey 2021-01-11 10:43 ` AMD64_LINUX_frame_size Florian Weimer 0 siblings, 2 replies; 7+ messages in thread From: Walt Drummond @ 2021-01-07 21:49 UTC (permalink / raw) To: Tom Tromey; +Cc: 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? 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AMD64_LINUX_frame_size 2021-01-07 21:49 ` AMD64_LINUX_frame_size Walt Drummond @ 2021-01-09 20:14 ` Tom Tromey 2021-01-11 10:43 ` AMD64_LINUX_frame_size Florian Weimer 1 sibling, 0 replies; 7+ messages in thread From: Tom Tromey @ 2021-01-09 20:14 UTC (permalink / raw) To: Walt Drummond; +Cc: Tom Tromey, Walt Drummond via Gdb Walt> Thanks Tom. My math shows the kernel sizes as Walt> Redzone 128 Walt> math frame/xstate 840 Walt> rt_sigframe 456 Walt> That's a total of 1424 bytes, so maybe GDB is saving less than it should? It seems to me that there's no need to save the red zone. However, I don't really know. All I can suggest is trying to write a test case and/or debug it to see. Tom ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AMD64_LINUX_frame_size 2021-01-07 21:49 ` AMD64_LINUX_frame_size Walt Drummond 2021-01-09 20:14 ` AMD64_LINUX_frame_size Tom Tromey @ 2021-01-11 10:43 ` Florian Weimer 2021-01-12 16:10 ` AMD64_LINUX_frame_size Walt Drummond 1 sibling, 1 reply; 7+ messages in thread From: Florian Weimer @ 2021-01-11 10:43 UTC (permalink / raw) To: Walt Drummond via Gdb; +Cc: Tom Tromey, Walt Drummond * 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: AMD64_LINUX_frame_size 2021-01-11 10:43 ` AMD64_LINUX_frame_size Florian Weimer @ 2021-01-12 16:10 ` Walt Drummond 0 siblings, 0 replies; 7+ messages in thread From: Walt Drummond @ 2021-01-12 16:10 UTC (permalink / raw) To: Florian Weimer; +Cc: Walt Drummond via Gdb, Tom Tromey 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 <fweimer@redhat.com> 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 > ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-01-12 16:10 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-04 18:30 AMD64_LINUX_frame_size Walt Drummond 2021-01-06 16:38 ` AMD64_LINUX_frame_size Walt Drummond 2021-01-07 21:19 ` AMD64_LINUX_frame_size Tom Tromey 2021-01-07 21:49 ` AMD64_LINUX_frame_size Walt Drummond 2021-01-09 20:14 ` AMD64_LINUX_frame_size Tom Tromey 2021-01-11 10:43 ` AMD64_LINUX_frame_size Florian Weimer 2021-01-12 16:10 ` AMD64_LINUX_frame_size Walt Drummond
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).