On Tue, Oct 07, 2014 at 05:51:53PM +0400, Ilya Verbin wrote:
> On 07 Oct 15:06, Jakub Jelinek wrote:
> > Still have issues with the non-installed testing.
>
> The idea was that the offload compiler should be installed.
>
> > If I add
> > -B /usr/src/gcc-git/objinst/usr/local/lib/gcc/x86_64-pc-linux-gnu/5.0.0/ \
> > -B /usr/src/gcc-git/objinst/usr/local/libexec/gcc/x86_64-pc-linux-gnu/5.0.0/
>
> Yes, since lto-wrapper uses COMPILER_PATH + "/accel/<target>/" to find
> mkoffload, it requires that the offload compiler with mkoffload are installed.
> Probably, it can be extended to search in the build paths, specified by
> --enable-offload-targets option.
>
> > to the command line so it at least finds mkoffload, it then can't find for
> > some reason the offload compiler:
>
> mkoffload itself also wants the offload compiler with correct name
> (<host>-accel-<target>-gcc). It can be extended to use xgcc. But I don't
> know,
> how to construct all paths for it (-B, -I, -L)?
>
> > So, what exactly should be added (by libgomp.exp) so that the testing
> > succeeds in
> > the case of non-installed offload and non-installed host compilers?
>
> Looks like, that non-installed offload compiler requires some complications.
> Is this really necessary?
I think it is useful, doesn't have to be in the initial checkin, but I'd
certainly prefer if from the (optional) --enable-offload-target argument
it would figure out everything it needs to add for testing.
And, if mkoffload isn't flexible enough to be convinced to find it in that
scenario, it better should be made more flexible.
Another thing I've noticed, when target-1.exe is built, there are tons of
sections that IMHO should have been stripped away:
[ 0] NULL 0000000000000000 000000 000000 00
0 0 0
[ 1] .interp PROGBITS 0000000000400238 000238 00001c 00 A
0 0 1
[ 2] .note.ABI-tag NOTE 0000000000400254 000254 000020 00 A
0 0 4
[ 3] .hash HASH 0000000000400278 000278 000094 04 A
4 0 8
[ 4] .dynsym DYNSYM 0000000000400310 000310 0001b0 18 A
5 1 8
[ 5] .dynstr STRTAB 00000000004004c0 0004c0 000189 00 A
0 0 1
[ 6] .gnu.version VERSYM 000000000040064a 00064a 000024 02 A
4 0 2
[ 7] .gnu.version_r VERNEED 0000000000400670 000670 000070 00 A
5 2 8
[ 8] .rela.dyn RELA 00000000004006e0 0006e0 000018 18 A
4 0 8
[ 9] .rela.plt RELA 00000000004006f8 0006f8 000150 18 A
4 11 8
[10] .init PROGBITS 0000000000400848 000848 00001a 00 AX
0 0 4
[11] .plt PROGBITS 0000000000400870 000870 0000f0 10 AX
0 0 16
[12] .text PROGBITS 0000000000400960 000960 000b44 00 AX
0 0 16
[13] .fini PROGBITS 00000000004014a4 0014a4 000009 00 AX
0 0 4
[14] .rodata PROGBITS 00000000004014b0 0014b0 000020 00 A
0 0 8
[15] .eh_frame_hdr PROGBITS 00000000004014d0 0014d0 000094 00 A
0 0 4
[16] .eh_frame PROGBITS 0000000000401568 001568 00032c 00 A
0 0 8
[17] .init_array INIT_ARRAY 0000000000601dd8 001dd8 000010 00 WA
0 0 8
[18] .fini_array FINI_ARRAY 0000000000601de8 001de8 000008 00 WA
0 0 8
[19] .jcr PROGBITS 0000000000601df0 001df0 000008 00 WA
0 0 8
[20] .dynamic DYNAMIC 0000000000601df8 001df8 000200 10 WA
5 0 8
[21] .got PROGBITS 0000000000601ff8 001ff8 000008 08 WA
0 0 8
[22] .got.plt PROGBITS 0000000000602000 002000 000088 08 WA
0 0 8
[23] .data PROGBITS 00000000006020a0 0020a0 000120 00 WA
0 0 32
[24] .offload_image_section PROGBITS 00000000006021c0 0021c0 003439 00
WA 0 0 16
[25] __gnu_offload_funcs PROGBITS 0000000000605600 005600 000018 00
WA 0 0 8
[26] __gnu_offload_vars PROGBITS 0000000000605618 005618 000010 00 WA
0 0 8
[27] .bss NOBITS 0000000000605628 005628 000008 00 WA
0 0 4
[28] .comment PROGBITS 0000000000000000 005628 000055 01 MS
0 0 1
[29] .gnu.target_lto_.profile.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 00567d 000014 00 0 0 1
[30] .gnu.target_lto_.jmpfuncs.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 005691 000028 00 0 0 1
[31] .gnu.target_lto_.inline.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 0056b9 000130 00 0 0 1
[32] .gnu.target_lto_.pureconst.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 0057e9 00001d 00 0 0 1
[33] .gnu.target_lto_fn2._omp_fn.1.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 005806 0005fc 00 0 0 1
[34] .gnu.target_lto_fn2._omp_fn.0.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 005e02 000765 00 0 0 1
[35] .gnu.target_lto_fn3._omp_fn.3.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 006567 0005a7 00 0 0 1
[36] .gnu.target_lto_fn3._omp_fn.2.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 006b0e 000435 00 0 0 1
[37] .gnu.target_lto_fn4._omp_fn.5.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 006f43 00066b 00 0 0 1
[38] .gnu.target_lto_fn4._omp_fn.4.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 0075ae 0004fc 00 0 0 1
[39] .gnu.target_lto_tgt.3e3ce5aae4e95dd4 PROGBITS 0000000000000000
007aaa 000160 00 0 0 1
[40] .gnu.target_lto_.symbol_nodes.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 007c0a 0000fe 00 0 0 1
[41] .gnu.target_lto_.refs.3e3ce5aae4e95dd4 PROGBITS 0000000000000000
007d08 00002c 00 0 0 1
[42] .gnu.target_lto_.offload_table.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 007d34 000017 00 0 0 1
[43] .gnu.target_lto_.decls.3e3ce5aae4e95dd4 PROGBITS 0000000000000000
007d4b 000a77 00 0 0 1
[44] .gnu.target_lto_.symtab.3e3ce5aae4e95dd4 PROGBITS
0000000000000000 0087c2 000027 00 0 0 1
[45] .gnu.target_lto_.opts PROGBITS 0000000000000000 0087e9 000083 00
0 0 1
[46] .shstrtab STRTAB 0000000000000000 00886c 000405 00
0 0 1
[47] .symtab SYMTAB 0000000000000000 0098b8 000cc0 18
48 91 8
[48] .strtab STRTAB 0000000000000000 00a578 0005f5 00
0 0 1
I thought .gnu.target_lto* sections hold LTO bytecore and are desirable only in
the
ET_REL objects for ld(1)/lto-wrapper purposes. For large programs containing
large
target regions the LTO bytecode could be very big, so leaving it in the binary
is
undesirable.
For .offload_image_section name, wouldn't it be better to prefix that with .gnu?
And, is __gnu_offload_{funcs,vars} named that way just because the plugin isn't
able to add
symbols around the sections for you? As it doesn't contain a dot, it would
collide
with user declarations put into __attribute__((section
("__gnu_offload_funcs"))).
Looking at the symbols:
73: 0000000000605618 16 OBJECT LOCAL DEFAULT 26 .omp_var_table
74: 0000000000605600 24 OBJECT LOCAL DEFAULT 25 .omp_func_table
78: 00000000006055f9 0 NOTYPE LOCAL DEFAULT 24
_offload_image_intelmic_end
79: 00000000006021d0 0 NOTYPE LOCAL DEFAULT 24
_offload_image_intelmic_start
102: 0000000000605600 0 OBJECT GLOBAL HIDDEN 25 _omp_func_table
118: 00000000006021a0 0 OBJECT GLOBAL HIDDEN 23 __OPENMP_TARGET__
124: 00000000006021c0 16 OBJECT GLOBAL HIDDEN 24
__OPENMP_TARGET_DATA__
130: 0000000000605628 0 OBJECT GLOBAL HIDDEN 26 _omp_vars_end
133: 0000000000605618 0 OBJECT GLOBAL HIDDEN 25 _omp_funcs_end
135: 0000000000605618 0 OBJECT GLOBAL HIDDEN 26 _omp_var_table
perhaps it would be better to have . somewhere in the names too, though if you
are
accessing that from C or declaring them in C, it might be too hard to bother.
It is all in reserved namespace anyway, but use two underscores prefix instead
of one
for those IMHO.
Jakub
