Error during linking after clang compile

[Bradley Venables]

Hi,

I've been trying to characterize an annoying compilation error all day, so I thought I would ping the group to see if anyone has experienced it. (I don't have the newest versions of tools, so perhaps this is a known problem.) It is worth noting that I have added custom instructions to my version of llvm that are unknown to gcc, so I need to create ELF files with clang and link with gcc. I also work exclusively in 32b.

I have 3 files: main.cpp, init.cpp, mymath.cpp (and corresponding headers)

The test is a very simple program where main() calls init() in init.cpp and init calls mathfcn() in mymath.cpp.

If I compile all 3 files with clang, linking fails:

$ clang++ -target riscv -mriscv=RV32IMAFD -integrated-as -c init.cpp main.cpp mymath.cpp

$ riscv32-unknown-elf-g++ -m32 -march=RV32IMAFD -o fft *.o

collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped

compilation terminated.

If I compile main.cpp with gcc and the other files with clang, the linker does not fail:

$ clang++ -target riscv -mriscv=RV32IMAFD -integrated-as -c init.cpp mymath.cpp

$ riscv32-unknown-elf-g++ -m32 -march=RV32IMAFD -c main.cpp

$ riscv32-unknown-elf-g++ -m32 -march=RV32IMAFD -o fft *.o

If only main() calls functions in mymath (i.e. main() can call init() and mathfcn() but they don't call each other), the linker also does not fail even when all files are compiled with clang.

The error assertion is triggered in _bfd_riscv_relax_call() procedure of the elfnn-riscv.c file, which is commented with "Relax AUIPC + JALR into JAL.", here:

/* Shorten the function call.  */

BFD_ASSERT (rel->r_offset + 8 <= sec->size);

Any insight would be appreciated.

Brad Venables

[Stefan O'Rear]

On Wed, Nov 30, 2016 at 3:43 PM, Bradley Venables
<threep...@gmail.com> wrote:
> I've been trying to characterize an annoying compilation error all day, so I
> thought I would ping the group to see if anyone has experienced it. (I don't
> have the newest versions of tools, so perhaps this is a known problem.) It
> is worth noting that I have added custom instructions to my version of llvm
> that are unknown to gcc, so I need to create ELF files with clang and link
> with gcc. I also work exclusively in 32b.

Last I heard there are serious codegen bugs in the published version
of riscv-llvm, and I'm not convinced it'll work for you even if the
linker did work.

> I have 3 files: main.cpp, init.cpp, mymath.cpp (and corresponding headers)
> The test is a very simple program where main() calls init() in init.cpp and
> init calls mathfcn() in mymath.cpp.
>
> If I compile all 3 files with clang, linking fails:
>
> $ clang++ -target riscv -mriscv=RV32IMAFD -integrated-as -c init.cpp
> main.cpp mymath.cpp
> $ riscv32-unknown-elf-g++ -m32 -march=RV32IMAFD -o fft *.o
> collect2: fatal error: ld terminated with signal 11 [Segmentation fault],
> core dumped

Naturally, whatever clang does do, ld is a separate project that we
think works. If you can make .o files (without proprietary code) that
cause ld to segfault, I suggest making a bug against
https://github.com/riscv/riscv-binutils-gdb and including the
offending .o files, because in isolation that is a bug in ld.

> The error assertion is triggered in _bfd_riscv_relax_call() procedure of the
> elfnn-riscv.c file, which is commented with "Relax AUIPC + JALR into JAL.",
> here:
>
> /* Shorten the function call. */
>
> BFD_ASSERT (rel->r_offset + 8 <= sec->size);
>
>
> Any insight would be appreciated.

The current relaxer code is a bit sketchy IMO. I think the plan is to
rewrite it after I finish the functional documentation I promised
Andrew.

I've never seen it *literally crash* but we have had to use
-Wl,--no-relax in a few places in Fedora to work around relaxer bugs.
That's an option for the gcc driver; it might work with clang as well,
or just --no-relax if you're calling ld directly.

-s

[Bradley Venables]

Thank you Stefan! 

Using the --no-relax flag in ld indeed allowed my program to compile and run. I guess the clang generated ELF files are okay (at least for this simple test) but throw an unexpected curve at gcc.

Brad.

--

Brad Venables

613-825-4452

c. 613-794-8242