gcc@gcc.gnu.org
+
___
开*各*地*正*规 3%（普-增）点优-惠，包真。
*
详电：陈先生
手机 ：138-243-97-979
**
业务QQ：182-185-1661
++
Snapshot gcc-8-20190517 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190517/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
On 5/17/19 2:51 PM, Tom Horsley wrote:
> I'm trying (for reason too complex to go into) to
> locate the TLS offset of the tcache_shutting_down
> variable from malloc in the ubuntu provided
> glibc on aarch64 ubuntu 18.04.
>
> Various "normal" TLS variables appear to operate
> much like x86_64 with
I'm trying (for reason too complex to go into) to
locate the TLS offset of the tcache_shutting_down
variable from malloc in the ubuntu provided
glibc on aarch64 ubuntu 18.04.
Various "normal" TLS variables appear to operate
much like x86_64 with a GOT table entry where the
TLS offset of the variab
Hi Eric,
Thanks for the information! Sorry to know dual entry isn't supported
well on VxWorks.
Thanks,
Kewen
on 2019/5/17 下午3:24, Eric Botcazou wrote:
>> I do think so. The call is locally, linker should know it's local and
>> fix it up with local entry instead. We don't need to keep r12 alwa
> I do think so. The call is locally, linker should know it's local and
> fix it up with local entry instead. We don't need to keep r12 always
> hold the entry of being called function.
Yes, but on VxWorks in kernel mode you first do partial linking and then the
loader resolves the remaining re
