Question about -moutline-atomic under -mcmodel-large
Hi,
Compiling below program:
#define STREAM_ARRAY_SIZE (1107296256)
double a[STREAM_ARRAY_SIZE],
b[STREAM_ARRAY_SIZE],
c[STREAM_ARRAY_SIZE];
typedef struct {
volatile int locked;
} spinlock_t;
volatile int cnt32=0;
volatile long cnt64=0;
void atom(){
__atomic_fetch_add(&cnt32, 1,__ATOMIC_RELAXED);
}
int main()
{
atom();
a[13] = b [23] = c [17] = (double)cnt32;
return 0;
}
with command line like:
$ gcc -O2 a.c -o a.out -march=armv8-a -mcmodel=large
/usr/lib/gcc/aarch64-linux-gnu/11/libgcc.a(lse-init.o): in function
`init_have_lse_atomics':
(.text.startup+0x14): relocation truncated to fit:
R_AARCH64_ADR_PREL_PG_HI21 against `.bss'
/usr/lib/gcc/aarch64-linux-gnu/11/libgcc.a(ldadd_4_1.o): in function
`__aarch64_ldadd4_relax':
(.text+0x4): relocation truncated to fit: R_AARCH64_ADR_PREL_PG_HI21
against symbol `__aarch64_have_lse_atomics' defined in .bss section in
/usr/lib/gcc/aarch64-linux-gnu/11/libgcc.a(lse-init.o)
collect2: error: ld returned 1 exit status
R_AARCH64_ADR_PREL_PG_HI21 is generated against __aarch64_ldadd4_relax
in lse-init.c and lse.S. Not sure if this is a break on
-mcmodel=large? Or is this as expected?
-mcmodel=large
Generate code for the large code model. This makes no assumptions
about addresses and sizes of sections. Programs can be statically
linked only. The -mcmodel=large option is incompatible with
-mabi=ilp32, -fpic and -fPIC.
What I am not sure is the meaning of "statically linked".
On the other hand, the error can be fixed by using adrps to :got:
entry for __aarch64_have_lse_atomics in lse.S, but not for lse-init.o
in which the symbol is considered local definition in C code.
Last question is why do we have __aarch64_have_lse_atomics(and some
other symbols) in both libgcc and glibc?
#objdump -t /usr/lib64/libc.so.6 | grep "__aarch64_ldadd"
00111460 l F .text 0030
__aarch64_ldadd8_acq
00111370 l F .text 0030
__aarch64_ldadd8_relax
001114c0 l F .text 0030
__aarch64_ldadd8_rel
001113d0 l F .text 0030
__aarch64_ldadd4_acq
#objdump -t /usr/lib/gcc/aarch64-linux-gnu/10/libgcc.a | grep "__aarch64_ldadd8"
g F .text 0030 .hidden __aarch64_ldadd8_relax
g F .text 0030 .hidden __aarch64_ldadd8_acq
g F .text 0030 .hidden __aarch64_ldadd8_rel
g F .text 0030 .hidden
__aarch64_ldadd8_acq_rel
Any idea when each version will be used?
Thanks,
bin
desired behavior or missing warning?
I found myself with code similar to this:
struct base {
virtual void cb() = 0;
};
struct deriv final : public base {
void cb() final override { }
};
The question is about the second use of 'final'. Because the entire
class is declared final, should the individual function's annotation be
flagged with a warning? I personally think it should because it might
distract from the final of the class itself.
signature.asc
Description: OpenPGP digital signature
Re: Question about -moutline-atomic under -mcmodel-large
* Bin Cheng via Gcc: > Last question is why do we have __aarch64_have_lse_atomics(and some > other symbols) in both libgcc and glibc? > > #objdump -t /usr/lib64/libc.so.6 | grep "__aarch64_ldadd" > > 00111460 l F .text 0030 > __aarch64_ldadd8_acq > > 00111370 l F .text 0030 > __aarch64_ldadd8_relax > > 001114c0 l F .text 0030 > __aarch64_ldadd8_rel > > 001113d0 l F .text 0030 > __aarch64_ldadd4_acq I'm pretty sure those symbols are unexpected symbols in .symtab, i.e., your libc.so.6 is not stripped (which helps debuggers and valgrind). Since glibc uses atomics, it needs to be linked against libgcc.a, and these symbols show up with -moutline-atomics. For your other question, on other targets, it is necessary to rebuild the entire toolchain if you want large code model support. As you saw, some of the pre-built statically linked bits are incompatible with that otherwise. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
Re: Question about -moutline-atomic under -mcmodel-large
On Thu, Sep 17, 2020 at 12:56:59PM +0200, Florian Weimer via Gcc wrote: > * Bin Cheng via Gcc: > > > Last question is why do we have __aarch64_have_lse_atomics(and some > > other symbols) in both libgcc and glibc? > > > > #objdump -t /usr/lib64/libc.so.6 | grep "__aarch64_ldadd" > > > > 00111460 l F .text 0030 > > __aarch64_ldadd8_acq > > > > 00111370 l F .text 0030 > > __aarch64_ldadd8_relax > > > > 001114c0 l F .text 0030 > > __aarch64_ldadd8_rel > > > > 001113d0 l F .text 0030 > > __aarch64_ldadd4_acq > > I'm pretty sure those symbols are unexpected symbols in .symtab, i.e., > your libc.so.6 is not stripped (which helps debuggers and valgrind). The symbols should be STV_HIDDEN, yes, they should show up in .symtab if not stripped, but not in .dynsym. The point of -moutline-atomics is that the symbols appear in every shared library and every binary that uses them to avoid the PLT costs (at the cost of having to initialize the var in every library/binary separately). Jakub
Re: Question about -moutline-atomic under -mcmodel-large
* Florian Weimer: > * Bin Cheng via Gcc: > >> Last question is why do we have __aarch64_have_lse_atomics(and some >> other symbols) in both libgcc and glibc? >> >> #objdump -t /usr/lib64/libc.so.6 | grep "__aarch64_ldadd" >> >> 00111460 l F .text 0030 >> __aarch64_ldadd8_acq >> >> 00111370 l F .text 0030 >> __aarch64_ldadd8_relax >> >> 001114c0 l F .text 0030 >> __aarch64_ldadd8_rel >> >> 001113d0 l F .text 0030 >> __aarch64_ldadd4_acq > > I'm pretty sure those symbols are unexpected symbols in .symtab, i.e., > your libc.so.6 is not stripped (which helps debuggers and valgrind). Sorry, I ment to write “unexported” instead of “unexpected”. Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
gcc-8-20200917 is now available
Snapshot gcc-8-20200917 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200917/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 550a13d7163a480aa6158bae54dfd080995884d9 You'll find: gcc-8-20200917.tar.xzComplete GCC SHA256=b8386a44a70e393efa9f1fbb3b944cc38d6b5bd95eecd9b9ec2384608b607ebf SHA1=1d9108f56deb8d55e43c064b600d5d794d589a8e Diffs from 8-20200910 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.
