On Fri, Sep 25, 2020, 1:45 PM Kinsey Moore <kinsey.mo...@oarcorp.com> wrote:
> -----Original Message-----
> From: Sebastian Huber <sebastian.hu...@embedded-brains.de>
> Sent: Friday, September 25, 2020 11:20
> To: Kinsey Moore <kinsey.mo...@oarcorp.com>; devel@rtems.org
> Subject: Re: [PATCH v1 6/8] score: Add AArch64 port
>
> On 25/09/2020 17:27, Kinsey Moore wrote:
>
> > diff --git a/cpukit/include/rtems/score/tls.h
> > b/cpukit/include/rtems/score/tls.h
> > index 65a49d87be..8c15eee569 100644
> > --- a/cpukit/include/rtems/score/tls.h
> > +++ b/cpukit/include/rtems/score/tls.h
> > @@ -85,7 +85,7 @@ typedef struct TLS_Thread_control_block {
> > struct TLS_Thread_control_block *tcb;
> > #else /* !__i386__ */
> > TLS_Dynamic_thread_vector *dtv;
> > -#if CPU_SIZEOF_POINTER == 4
> > +#if CPU_SIZEOF_POINTER == 4 || CPU_SIZEOF_POINTER == 8
> > uintptr_t reserved;
> > #endif
> > #endif /* __i386__ */
> Are you sure this is correct? TLS_Dynamic_thread_vector *dtv; is 8 bytes
> in this case.
> []
> Dropping this change causes sptls01 to fail. This was added pretty early
> in the implementation, so I've just had to go back and refresh my memories
> of the reasoning behind it which still may not be entirely accurate.
> Sptls01 fails without this patch because under AArch64/LP64, gcc and gdb
> expect a 16 byte offset to the TLS data segment. If this patch is not
> present, the TCB is half the size it needs to be and so getting a TLS
> variable address ends up indexing into the TCB+TLS data segment at a
> compiler-expected offset that does not correspond to the actual data
> layout. I adjusted this to match the compiler's offset expectations. There
> may be a better way to fix this issue, but this is the most appropriate
> location I could find that made the most sense. The biggest worry I have
> here is that this may break other architectures that also have 8 byte
> pointers. When I fix the file headers, I'll see if I can make this more
> specific to AArch64.
>
Make sure your explanation his into a comment above this. Memory fades
quickly and that's why comments for odd cases like this need to be good.
I'll be the first to admit that I have had to add comments after
rediscovering the reason for some odd bit of code. Personally, I think
these types of comments are part of the value RTEMS brings.
--joel
>
> Kinsey
> _______________________________________________
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
