[Lldb-commits] [lldb] r353778 - Define _ENABLE_EXTENDED_ALIGNED_STORAGE on Windows.

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Fri Feb 15 04:22:35 PST 2019


Ah, it's our struct XSAVE friend again. Yeah, I think I have a pretty 
good idea of what this is doing, and I believe we don't need any special 
alignment there, so I just went ahead and removed it. Assuming this 
doesn't cause any issues, you should be able to revert this patch.

On 13/02/2019 18:46, Jonas Devlieghere wrote:
> Hi Pavel,
> 
> I think the offending struct is XSAVE in RegisterContext_x86.h. I don't 
> really know this code, would you mind having a look? It looks like you 
> touched the alignment in the past and seems to know what this this is 
> doing :-)
> 
> tree f8fc1af1c62b728260b6c950649c55f7aba513f6
> parent 6857692687979d934e188d117eadc93f48d52a0c
> author Pavel Labath <pavel at labath.sk <mailto:pavel at labath.sk>> Wed Sep 
> 12 08:50:08 2018 +0000
> committer Pavel Labath <pavel at labath.sk <mailto:pavel at labath.sk>> Wed 
> Sep 12 08:50:08 2018 +0000
> 
> Reduce alignment on struct XSAVE, fixing a gcc warning
> 
> The warning is about heap-allocating a struct with bigger alignment
> requirements than the standard heap allocator provides.
> 
> AFAICT, all uses of the XSAVE struct are already heap-allocated, so this
> high alignment does not actually have any effect and removing it should
> be NFC.
> 
> I have also done some digging in the commit history. This alignment
> requirement was since the XSAVE struct was introduced in r180572 when
> adding AVX register support for linux. It does not mention the alignment
> specifically, so I am guessing this was just put there because the
> corresponging XSAVE cpu instruction requires its buffer to be 64-byte
> aligned. However, LLDB will not be normally reading this struct via the
> XSAVE instruction directly. Instead we will ask the kernel to copy the
> buffer saved when suspeding the inferior. This should not require such
> strict alignment (in fact, linux kernel will happily do this for any
> alignment).
> 
> llvm-svn: 342029
> 
> 
> 
> 
> 
> On Mon, Feb 11, 2019 at 10:55 PM Pavel Labath <pavel at labath.sk 
> <mailto:pavel at labath.sk>> wrote:
> 
>     On 12/02/2019 01:30, Jonas Devlieghere via lldb-commits wrote:
>      > Author: jdevlieghere
>      > Date: Mon Feb 11 16:30:21 2019
>      > New Revision: 353778
>      >
>      > URL: http://llvm.org/viewvc/llvm-project?rev=353778&view=rev
>      > Log:
>      > Define _ENABLE_EXTENDED_ALIGNED_STORAGE on Windows.
>      >
>      > Apparently there are multiple places where MSVC complains about
>      > instantiations with extended aligment. I think it's better to define
>      > `_ENABLE_EXTENDED_ALIGNED_STORAGE` as suggested by the error message.
>      >
>      > I don't have access to a Windows machine so this is all speculative.
>      >
> 
>     I think it would be worth investigating where is this large alignment
>     coming from (my guess: something inside the RegisterContextDarwin
>     structs). We've had a case in the past where we were heap-allocating a
>     struct with a 64-byte alignment. MSVC would give a warning there, but
>     gcc&clang would silently under-align the result.
> 
>     In that case, the large alignment was actually unneeded, so I fixed
>     both
>     issues by just lowering it. I suspect something similar may be possible
>     here.
> 
>     pl
> 



More information about the lldb-commits mailing list