Re: TLS details on Linux for x86 and x64

2017-12-03 Thread Liu Hao 
On 2017/12/3 1:00, Andrew Haley wrote:
> Have you read
> 
> https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt
> 
> ?
> 

No. Well, will do. Thanks for the information.


-- 
Best regards,
LH_Mouse

Re: TLS details on Linux for x86 and x64

2017-12-03 Thread Jakub Jelinek 
On Sat, Dec 02, 2017 at 05:00:23PM +, Andrew Haley wrote:
> On 02/12/17 14:04, Liu Hao wrote:
> > 
> > 0) What is the magical `@tpoff` suffix supposed to do? The `@ntpoff` and
> > `@dtpoff` things are documented in System V ABI but there doesn't seem
> > to be anything about `@tpoff`.
> > 1) How does LD tell that `b` (a thread-local integer) is different from
> > `a` (a static integer)? `a` is apparently offset from RIP, but what
> > thing is `b` offset from?
> > 2) TLS initializers are placed into specially named sections. The
> > sections will have the names like `.tls$XXX` where `$XXX` is used to
> > sort these sections and discarded thereafter. How is LD supposed to
> > associate the section containing the initializer with the symbol of
> > object being initialized, without disordering?
> > 
> > Any help will be appreciated.
> 
> Have you read
> 
> https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt
> 
> ?

Well, for GNU TLS (rather than GNU2) you want to read
https://www.akkadia.org/drepper/tls.pdf

Jakub

Re: TLS details on Linux for x86 and x64

2017-12-03 Thread Liu Hao 
On 2017/12/3 18:50, Jakub Jelinek wrote:
> Well, for GNU TLS (rather than GNU2) you want to read
> https://www.akkadia.org/drepper/tls.pdf
> 
>   Jakub
> 

Thank you too. I am thinking about migrating the technique used by GCC
on Linux to Windows, minimizing modification by our side, since it
should be considered to be essentially bugfree and stable.


-- 
Best regards,
LH_Mouse

Re: TLS details on Linux for x86 and x64

2017-12-03 Thread Andrew Haley 
On 03/12/17 10:50, Jakub Jelinek wrote:
> On Sat, Dec 02, 2017 at 05:00:23PM +, Andrew Haley wrote:
>> On 02/12/17 14:04, Liu Hao wrote:
>>>
>>> 0) What is the magical `@tpoff` suffix supposed to do? The `@ntpoff` and
>>> `@dtpoff` things are documented in System V ABI but there doesn't seem
>>> to be anything about `@tpoff`.
>>> 1) How does LD tell that `b` (a thread-local integer) is different from
>>> `a` (a static integer)? `a` is apparently offset from RIP, but what
>>> thing is `b` offset from?
>>> 2) TLS initializers are placed into specially named sections. The
>>> sections will have the names like `.tls$XXX` where `$XXX` is used to
>>> sort these sections and discarded thereafter. How is LD supposed to
>>> associate the section containing the initializer with the symbol of
>>> object being initialized, without disordering?
>>>
>>> Any help will be appreciated.
>>
>> Have you read
>>
>> https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt
>>
>> ?
> 
> Well, for GNU TLS (rather than GNU2) you want to read
> https://www.akkadia.org/drepper/tls.pdf

Ah, thanks.  I thought that it was much the same.

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

gcc-8-20171203 is now available

2017-12-03 Thread gccadmin 
Snapshot gcc-8-20171203 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20171203/
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/trunk revision 255368

You'll find:

 gcc-8-20171203.tar.xzComplete GCC

  SHA256=c53fc75277fa6730330d8e766d0110a561182c9a0a41f29563fa9065d632e029
  SHA1=427e90b3a8440a8e3cb1b010afd85e9195e7253e

Diffs from 8-20171126 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.

dead code remover under gcc -O and higher(Is there a flag to do this)

2017-12-03 Thread chengjian (D) 

I have written a simple code like this

```c
#include 
#include 

//#define CONFIG_TARGET_X86_64

#ifdef CONFIG_TARGET_X86_64
static void A( )
{
printf("A\n");
}
#else
void A( );
#endif

static void B( )
{
printf("B\n");
}


static int xx( )
{
#ifdef CONFIG_TARGET_X86_64
  return 1;
#else
  return 0;
#endif
}

int main(void)
{
  if (xx( ))   /* define CONFIG_TARGET_X86_64 */
A( );
  else
B( );
}
```

If we don't define the CONFIG_TARGET_X86_64, xx( ) will always return 
FALSE, so functiopn A which is only declared, but not implemented will 
never be called(dead code).


compile it with gcc -O0

```cpp
/tmp/cctSpgGk.o: In function `main':
1.c:(.text+0x34): undefined reference to `A'
collect2: error: ld returned 1 exit status
```

But it can be compiled by -O1 or higher.

use GCC V6.1.0.

I can declare A as weak:

```cpp
void A (void) __attribute__ ((weak));
```

Then the linker will ignore the undefined symbol reference, but a call 
to this function will lead to a crash



So my question is :
It seems that one of the optimization options in the -O1 option 
eliminates the dead code, I have seen the optimize doccument about GCC


https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Optimize-Options.html

but I can't find it.

So if I just want to compile this code under the -O0 option, Is it 
possible ? Are there some optimization flags help me to do this?


Thanks.

Re: dead code remover under gcc -O and higher(Is there a flag to do this)

2017-12-03 Thread carl hansen 
line 12 , you say "void A( );"

say instead:
void A(){};

That solved it for me, using gcc7.2

On Sun, Dec 3, 2017 at 4:56 PM, chengjian (D)  wrote:
> I have written a simple code like this
>
> ```c
> #include 
> #include 
>
> //#define CONFIG_TARGET_X86_64
>
> #ifdef CONFIG_TARGET_X86_64
> static void A( )
> {
> printf("A\n");
> }
> #else
> void A( );
> #endif
>
> static void B( )
> {
> printf("B\n");
> }
>
>
> static int xx( )
> {
> #ifdef CONFIG_TARGET_X86_64
>   return 1;
> #else
>   return 0;
> #endif
> }
>
> int main(void)
> {
>   if (xx( ))   /* define CONFIG_TARGET_X86_64 */
> A( );
>   else
> B( );
> }
> ```
>
> If we don't define the CONFIG_TARGET_X86_64, xx( ) will always return FALSE,
> so functiopn A which is only declared, but not implemented will never be
> called(dead code).
>
> compile it with gcc -O0
>
> ```cpp
> /tmp/cctSpgGk.o: In function `main':
> 1.c:(.text+0x34): undefined reference to `A'
> collect2: error: ld returned 1 exit status
> ```
>
> But it can be compiled by -O1 or higher.
>
> use GCC V6.1.0.
>
> I can declare A as weak:
>
> ```cpp
> void A (void) __attribute__ ((weak));
> ```
>
> Then the linker will ignore the undefined symbol reference, but a call to
> this function will lead to a crash
>
>
> So my question is :
> It seems that one of the optimization options in the -O1 option eliminates
> the dead code, I have seen the optimize doccument about GCC
>
> https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Optimize-Options.html
>
> but I can't find it.
>
> So if I just want to compile this code under the -O0 option, Is it possible
> ? Are there some optimization flags help me to do this?
>
> Thanks.
>

Re: dead code remover under gcc -O and higher(Is there a flag to do this)

2017-12-03 Thread chengjian (D) 



On 2017/12/4 10:25, carl hansen wrote:

line 12 , you say "void A( );"

say instead:
void A(){};

That solved it for me, using gcc7.2




Yeah, I miss the implementation, but I did this on purpose

I'm curious is there any options to eliminate this.
like gcc -O2 do.

thanks.