Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .

[Eric Botcazou]

> 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 relocations.  None of them plays the usual dance 
with the local and global entry points implied by the ELFv2 ABI.

-- 
Eric Botcazou

Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .

[Kewen.Lin]

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 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 relocations.  None of them plays the usual 
> dance 
> with the local and global entry points implied by the ELFv2 ABI.
> 

aarch64 TLS optimizations?

[Tom Horsley]

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 variable gets stashed.

But in the ubuntu glibc there is no GOT entry for
that variable, and disassembly of the code shows
that it seems to "just know" the offset to use.

Is there some kind of magic TLS optimization that
can happen for certain variables on aarch64? I'm trying
to understand how it could know the offset like
it appears to do in the code.

Re: aarch64 TLS optimizations?

[Andrew Haley]

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 a GOT table entry where the
> TLS offset of the variable gets stashed.
> 
> But in the ubuntu glibc there is no GOT entry for
> that variable, and disassembly of the code shows
> that it seems to "just know" the offset to use.
> 
> Is there some kind of magic TLS optimization that
> can happen for certain variables on aarch64? I'm trying
> to understand how it could know the offset like
> it appears to do in the code.

https://www.fsfla.org/~lxoliva/writeups/TLS/paper-lk2006.pdf



-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

gcc-8-20190517 is now available

[gccadmin]

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-branch 
revision 271361

You'll find:

 gcc-8-20190517.tar.xzComplete GCC

  SHA256=b54645d79745f51a9f2c8b61efa845602bd540a0523aff8c917d6eed01a1d68f
  SHA1=7a6fe8e0cc157326485879f960521e2306edffeb

Diffs from 8-20190510 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

******（PIAO）%%%%

[fhsrim]

gcc@gcc.gnu.org
+
___
开*各*地*正*规 3%（普-增）点优-惠，包真。
*
详电：陈先生
手机 ：138-243-97-979
**
业务QQ：182-185-1661

++