Charm++ parallel programming system

[Jozsef Bakosi <jbakosi AT lanl.gov>]

Hi Evan,

$ gcc --version
gcc (Debian 7.3.0-12) 7.3.0

$ gcc -Wl,-v,--version
collect2 version 7.3.0
/usr/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so 
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper 
-plugin-opt=-fresolution=/tmp/ccrKEcYG.res -plugin-opt=-pass-through=-lgcc 
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc 
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ 
--build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu -dynamic-linker 
/lib64/ld-linux-x86-64.so.2 -pie 
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o 
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o 
/usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7 
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu 
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu 
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib 
-L/opt/intel/compilers_and_libraries_2017/linux/lib/intel64 
-L/opt/intel/compilers_and_libraries_2017/linux/mkl/lib/intel64 
-L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. -v --version -lgcc --as-needed 
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed 
/usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o 
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
GNU ld (GNU Binutils for Debian) 2.30
GNU ld (GNU Binutils for Debian) 2.30

I have done some digging, outside Charm++, but I have not been able to track
down exactly what causes this problem. Here is what I think I know:

* Only occurs with gcc, not with clang or intel

* Affects gcc versions 5, 6, and 7 (or perhaps more correctly: independent of 
gcc)

* Also (probably) independent of ld vs gold

* One suspect I have is binutils, as that provides the __executable_start
symbol. Older binutils appear to be fine. I tried with: 2.30 and 2.28 which 
both
fail but 2.25 works. (I did this with a clean new install (in a VM) of the
"stable" version of the distro (debian) I usually use, which had 2.25.) I
usually use close to the latest ("testing"), and that has 2.30 right now, 
which
is how I bumped into this.) However, I tested this on alpine linux, with
binutils 2.28 and that also fails without the patch.

Please let me know how I can help more.

Thanks,
Jozsef

On 05.01.2018 17:44, Evan Ramos wrote:
> If we cannot depend on the __executable_start symbol being present on
> all systems, we should definitely avoid obstructing the launch of all
> Charm++ programs. I've opened a ticket on our issue tracker:
> https://charm.cs.illinois.edu/redmine/issues/1893
> 
> Could you tell me if you are passing any additional options to the
> toolchain that might affect the presence of this symbol, as well as
> the output of `gcc --version` and `gcc -Wl,-v,--version` on the
> affected toolchain?
> 
> Regards,
> --
> Evan A. Ramos
> Software Engineer
> Charmworks, Inc.
> 
> 
> On Tue, May 1, 2018 at 3:25 PM, Jozsef Bakosi 
> <jbakosi AT lanl.gov>
>  wrote:
> > Thanks, Evan, that work-around does indeed work and we will use that for 
> > now. Is
> > there a way to fix this problem in Charm++ itself? Or perhaps, to turn 
> > off when
> > AMPI is not used?
> >
> > Thanks,
> > Jozsef
> >
> > On 04.30.2018 15:18, Evan Ramos wrote:
> >> Hi Jozsef,
> >>
> >> The only use of the `__executable_start` symbol in Charm++ is in
> >> cmitls.c. If you are not using the tlsglobals privatization feature of
> >> AMPI, you should be able to remove "cmitls.o" from Charm's
> >> src/scripts/Makefile to bypass the problem.
> >>
> >> Regards,
> >> --
> >> Evan A. Ramos
> >> Software Engineer
> >> Charmworks, Inc.