"GOT" under aarch64

[jacob navia]

Hi

I am writing a code generator for ARM64.

To access a global variable I was generating

    addrp x0,someglobal

    add    x0,[x0,:lo12:someglobal]


This worked without any problems with gcc version 4.9.2 (Debian/Linaro 
4.9.2-10) and GNU ld (GNU Binutils for Debian) 2.25.


I have updated my system and now with gcc version 6.3.0 20170516 (Debian 
6.3.0-18) and GNU ld (GNU Binutils for Debian) 2.28. The linker 
complains about illegal relocations.


Investigating this, I noticed that now gcc generates

 adrp    x0, :got:stderr
 ldr x0, [x0, #:got_lo12:stderr]

I changed now my code generator and it works again. The problem for me is:


1) How can I know what I should generate? Should I figure out the gcc 
version installed?


2) Is there any documentation for this change somewhere? What does it mean?

3) What should be a portable solution for this problem?

Thanks in advance for your time.

Jacob

Re: "GOT" under aarch64

[Florian Weimer]

* jacob navia:

> 1) How can I know what I should generate? Should I figure out the gcc 
> version installed?
>
> 2) Is there any documentation for this change somewhere? What does it mean?

It's probably due to a downstream packaging change to enable
position-independent executables (PIE) by default.

> 3) What should be a portable solution for this problem?

That depends on how you integrate with the GNU toolchain.

Re: "GOT" under aarch64

[Wilco Dijkstra]

Hi,

You'll get GOT relocations to globals when you use -fpic:

int x;
int f(void) { return x; }
>gcc -O2 -S -o- -fpic

f:
adrpx0, :got:x
ldr x0, [x0, #:got_lo12:x]
ldr w0, [x0]
ret

So it doesn't depend on the compiler but what options you compile for.
There may be an issue with your setup, -fpic shouldn't be on by default.
Use gcc -v -Q -c testfile.c to list all the default settings - there could be
more non-standard or inefficient options enabled.

Wilco

Re: "GOT" under aarch64

[Ramana Radhakrishnan]

On Fri, Sep 22, 2017 at 12:29 PM, Wilco Dijkstra  wrote:
> Hi,
>
> You'll get GOT relocations to globals when you use -fpic:
>
> int x;
> int f(void) { return x; }
>>gcc -O2 -S -o- -fpic
>
> f:
> adrpx0, :got:x
> ldr x0, [x0, #:got_lo12:x]
> ldr w0, [x0]
> ret
>
> So it doesn't depend on the compiler but what options you compile for.
> There may be an issue with your setup, -fpic shouldn't be on by default.

There's -fpic and there's -fpie. In this case it's more likely to be
pie which is about position independent executables. Distros and other
downstream packagers default to -fpie these days for security and
hardening reasons as it allows them to by default generate code that
is position independent and allows things like ASLR to actually take
effect.

To answer the question when are relocations through the GOT used, the
answer is whenever folks want to have position independence either in
their libraries or in their executables.

regards
Ramana

Re: GCC Buildbot

[Paulo Matos]

On 22/09/17 01:23, Joseph Myers wrote:
> On Thu, 21 Sep 2017, Paulo Matos wrote:
> 
>> Interesting suggestion. I haven't had the opportunity to look at the
>> compile farm. However, it could be interesting to have a mix of workers:
>> native compile farm ones and some x86_64 doing cross compilation and
>> testing.
> 
> Note that even without a simulator (but with target libc), you can test 
> just the compilation parts of the testsuite using a board file with a 
> dummy _load implementation.
> 

I was not aware of that. I will keep that in mind once I try to setup a
cross-compilation worker.

I assume you have done this before. Do you have any scripts for
cross-compiling you can share?

Thanks,

-- 
Paulo Matos

Re: GCC Buildbot

[Joseph Myers]

On Fri, 22 Sep 2017, Paulo Matos wrote:

> > Note that even without a simulator (but with target libc), you can test 
> > just the compilation parts of the testsuite using a board file with a 
> > dummy _load implementation.
> > 
> 
> I was not aware of that. I will keep that in mind once I try to setup a
> cross-compilation worker.
> 
> I assume you have done this before. Do you have any scripts for
> cross-compiling you can share?

Here is a board file (by Janis Johnson) that stubs out test execution (you 
still need to be able to link, and for some bare-metal configurations 
linking may not work by default without specifying a linker script that 
chooses a BSP).

load_generic_config "sim"
set_board_info hostname "dummy-run"
set board_info(localhost,isremote) 0
process_multilib_options ""

# Override ${target}_load to do nothing.
foreach t $target_list {
proc ${t}_load { args } {
send_user "dummy load does nothing\n"
return [list "unresolved" ""]
}
}

glibc's build-many-glibcs.py shows the preferred modern approach for 
bootstrapping a cross toolchain for a target using glibc.  (However, the 
set of configurations it builds aims at covering glibc configuration 
space, especially as regards ABIs, and is probably more than is relevant 
for testing GCC for those architectures.)  Tools such as crosstool-ng have 
recipes for building cross toolchains that may also be useful to look at, 
but many such tools often do things for glibc builds that haven't been 
necessary for several years.

For bare metal you'll want newlib instead of glibc (configure that with 
the same --build --host --target as GCC, since it's the same top-level 
build system, and that build system deals internally with making "host" 
for configuring the newlib subdirectory the same as "target" was at top 
level).

-- 
Joseph S. Myers
jos...@codesourcery.com

Tom de Vries appointed nvptx maintainer

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Tom de Vries as nvptx maintainer.

Please join me in congratulating Tom on his new role.
Tom, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

[Thomas Schwinge]

Hi!

On Thu, 21 Sep 2017 12:18:39 -0600, Carlos O'Donell  wrote:
> On 09/21/2017 11:56 AM, Richard Biener wrote:
> > On Thu, 21 Sep 2017 11:38:29 -0600, Carlos O'Donell  
> > wrote:
> > > On 09/21/2017 10:50 AM, Thomas Schwinge wrote:
> > > > So my question is, if I've gotten a patch reviewed by someone who is not
> > > > yet ;-) familiar with that new process, and I nevertheless want to
> > > > acknowledge their time invested in review by putting "Reviewed-by" into
> > > > the commit log, is it fine to do that if the reviewer just answered with
> > > > "OK" (or similar) instead of an explicit "Reviewed-by: NAME "
> > > > statement?
> > > You should instead ask the author to give their "Reviewed-by:" and point
> > > out what the Reviewed-by statement means.
> > > 
> > > > That is, is it fine to assume that our current patch review's standard
> > > > "OK" (or similar) answer matches the more formal "Reviewer's statement 
> > > > of
> > > > oversight"?
> > > 
> > > Not yet.
> > 
> > I think given an OK from an official reviewer entitles you to commit
> > it indeed IS matching the formal statement. It better does...

I certainly understand your rationale, and do agree to that -- yet, I can
see how somebody might get offended if turning a casual "OK" into a
formal "Reviewed-by: NAME ", so...

> Isn't it better to be explicit about this; rather than assuming?

..., yeah, that makes sense.

Anyway: aside from starting to use them, we should also document such new
processes, so we might do it as follows, where I had the idea that the
*submitter* 'should encourage the reviewer to "earn" this
acknowledgement'.

Gerald, OK to commit?  If approving this patch, please respond with
"Reviewed-by: NAME " so that your effort will be recorded.  See
.  There you go.  ;-)

Index: htdocs/contribute.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.87
diff -u -p -r1.87 contribute.html
--- htdocs/contribute.html  9 Apr 2015 21:49:31 -   1.87
+++ htdocs/contribute.html  22 Sep 2017 18:20:04 -
@@ -23,7 +23,7 @@ contributions must meet:
 Testing Patches
 Documentation Changes
 Web Site Changes
-Submitting Patches
+Preparing Patches
 Announcing Changes (to our Users)
 
 
@@ -164,7 +164,7 @@ file" mode of the validator.
 More about our web pages.
 
 
-Submitting Patches
+Preparing Patches
 
 Every patch must have several pieces of information, before we
 can properly evaluate it:
@@ -257,6 +257,71 @@ bzip2ed and uuencoded or encoded as a 
 
+
+Acknowledge Patch Review
+
+Patch review often is a time-consuming effort.  It is appreciated to
+  acknowledge this in the commit log.  We are adapting
+  the Reviewed-by: tag as established by the Linux kernel patch
+  review process.
+
+As this is not yet an established process in GCC, you, as the submitter,
+  should encourage the reviewer to "earn" this acknowledgement.  For example,
+  include the following in your patch submission:
+
+
+  If approving this patch, please respond with "Reviewed-by: NAME
+" so that your effort will be recorded.  See
+;.
+  
+
+
+For reference, reproduced from
+  the https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.13#n560";>Linux
+  kernel 4.13's Documentation/process/submitting-patches.rst:
+
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.13#n560";>
+  Reviewed-by: [...] indicates that the patch has been reviewed
+and found acceptable according to the Reviewer's Statement:
+
+Reviewer's statement of oversight
+
+By offering my Reviewed-by: tag, I state that:
+
+(a) I have carried out a technical review of this patch to
+evaluate its appropriateness and readiness for inclusion [...].
+
+
+(b) Any problems, concerns, or questions relating to the patch
+have been communicated back to the submitter.  I am satisfied
+with the submitter's response to my comments.
+
+
+(c) While there may be things that could be improved with this
+submission, I believe that it is, at this time, (1) a
+worthwhile modification [...], and (2) free of known
+issues which would argue against its inclusion.
+
+
+(d) While I have reviewed the patch and believe it to be sound, I
+do not (unless explicitly stated elsewhere) make any
+warranties or guarantees that it will achieve its stated
+purpose or function properly in any given situation.
+
+
+A Reviewed-by: tag is a statement of opinion that the patch is an
+appropriate modification [...] without any remaining serious
+technical issues.  Any interested reviewer (who has done the work) can
+offer a Reviewed-by: 

Re: Tom de Vries appointed nvptx maintainer

[Yao Qi]

On Fri, Sep 22, 2017 at 7:30 PM, David Edelsohn  wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Tom de Vries as nvptx maintainer.
>

Congratulations, Tom!

-- 
Yao (齐尧)

Weird warning when building gcc

[nick]

Greetings All,

I am wondering if this is a warning worth looking into or is it just another 
false postive:

/home/nick/gcc/gcc/combine.c:1316:8: warning: ‘prev’ may be used uninitialized 
in this function [-Wmaybe-uninitialized]
 if ((next = try_combine (insn, prev, NULL, NULL,

Maybe it's just me being new to the project but is the code for that literally 
or also identical between this and the 
one where CC0 register is directly used.

 if (HAVE_cc0
&& JUMP_P (insn)
&& (prev = prev_nonnote_insn (insn)) != 0
&& NONJUMP_INSN_P (prev)
&& sets_cc0_p (PATTERN (prev)))
  {
if ((next = try_combine (insn, prev, NULL, NULL,
 &new_direct_jump_p,
 last_combined_insn)) != 0)
  goto retry;
 
FOR_EACH_LOG_LINK (nextlinks, prev)
if ((next = try_combine (insn, prev, nextlinks->insn,
 NULL, &new_direct_jump_p,
 last_combined_insn)) != 0)
  goto retry;
  }
  

Without CC0 register explict:
/* Do the same for an insn that explicitly references CC0.  */
if (HAVE_cc0 && NONJUMP_INSN_P (insn)
&& (prev = prev_nonnote_insn (insn)) != 0
   && NONJUMP_INSN_P (prev)
   && sets_cc0_p (PATTERN (prev))
   && GET_CODE (PATTERN (insn)) == SET
   && reg_mentioned_p (cc0_rtx, SET_SRC (PATTERN (insn
 {
  if ((next = try_combine (insn, prev, NULL, NULL,
   &new_direct_jump_p,
   last_combined_insn)) != 0)
 goto retry;
 
   FOR_EACH_LOG_LINK (nextlinks, prev)
   if ((next = try_combine (insn, prev, nextlinks->insn,
NULL, &new_direct_jump_p,
last_combined_insn)) != 0)
   goto retry;
 }

Maybe it's just me being new here. Further more, was wondering if ctags support 
is there. I assume it's 
there but was unable to find anything in the build or configuration pages when 
building gcc. As these
are the only two lines that are different:

&& GET_CODE (PATTERN (insn)) == SET
&& reg_mentioned_p (cc0_rtx, SET_SRC (PATTERN (insn)))


Sorry if this a stupid question but it seems really weird to me,

Nick