AMD64_LINUX_frame_size

AMD64_LINUX_frame_size

[Walt Drummond]

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.

Re: AMD64_LINUX_frame_size

[Walt Drummond]

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

Re: AMD64_LINUX_frame_size

[Tom Tromey]

>>>>> "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

Re: 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

Re: AMD64_LINUX_frame_size

[Tom Tromey]

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

Re: AMD64_LINUX_frame_size

[Florian Weimer]

* 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

Re: AMD64_LINUX_frame_size

[Walt Drummond]

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
>