* 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).