Bug 229155 - "Unsupported relocation type 11 in non-PLT relocations" when running compiled binary
Summary: "Unsupported relocation type 11 in non-PLT relocations" when running compiled...
Status: Closed Unable to Reproduce
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-toolchain mailing list
URL:
Keywords: needs-qa, toolchain
Depends on:
Blocks:
 
Reported: 2018-06-19 12:40 UTC by Gleb Popov
Modified: 2019-07-18 11:00 UTC (History)
3 users (show)

See Also:
koobs: mfc-stable12?


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gleb Popov freebsd_committer 2018-06-19 12:40:30 UTC
I'm trying to compile TensorFlow library and during build it produces helper executables that generate some app-specific code. Some of these helper executables get broken: when running them they yield something like

bin/tensorflow/cc/ops/candidate_sampling_ops_gen_cc: Unsupported relocation type 11 in non-PLT relocations

To make it easier to reproduce the bug, I've created a preliminary port, see https://reviews.freebsd.org/D15902

Steps to reproduce:

1. cd into your ports dir

2. arc patch D15902 to pull the patch in, or do it manually

3. make build BAZEL_EXTRA_ARGS="-s" BAZEL_TARGET=//tensorflow/cc:ops1/candidate_sampling_ops_gen_cc
This will produce "work/tensorflow-1.8.0/bazel-bin/tensorflow/cc/ops/candidate_sampling_ops_gen_cc" binary.

4. Either try running it manually or try building another target that uses this executable:

rm work/.build_done.tensorflow._usr_local
make build BAZEL_EXTRA_ARGS="-s" BAZEL_TARGET=//tensorflow/cc:candidate_sampling_ops_genrule
Comment 1 Ed Maste freebsd_committer 2018-06-21 23:50:16 UTC
I presume this is amd64?

#define R_X86_64_32S            11      /* Add 32 bit sign extended symbol value */

                /*                                                              
                 * missing:                                                     
                 * R_X86_64_GOTPCREL, R_X86_64_32, R_X86_64_32S, R_X86_64_16,   
                 * R_X86_64_PC16, R_X86_64_8, R_X86_64_PC8                      
                 */                                                             
                default:                                                        
                        _rtld_error("%s: Unsupported relocation type %u"        
                            " in non-PLT relocations\n", obj->path,             
                            (unsigned int)ELF_R_TYPE(rela->r_info));            
                        goto done;                                              

The missing R_X86_64_32S comment comes from r115280:

    Initial pass at supporting shared libraries on amd64.  There are still
    a few missing relocation types in amd64/reloc.c, but I have not found
    any of them in use yet. :-)
Comment 2 Gleb Popov freebsd_committer 2018-06-22 08:11:22 UTC
(In reply to Ed Maste from comment #1)

Yep, amd64. This comment looks like a cause.
Comment 3 Gleb Popov freebsd_committer 2018-07-14 16:25:45 UTC
Can anything be done with this? I'd like to continue TensorFlow porting effort.
Comment 4 Julien Cigar 2018-12-19 12:03:44 UTC
Although not related to TensorFlow, I have the same problem when I try to compile an old Ruby interpreter (1.9.3):

this is the command I used:

CC=clang CXX=clang++ CPP=clang-cpp RUBY_CONFIGURE_OPTS="--enable-shared" MAKE="make" MAKE_OPTS="-j1" LDFLAGS="-Wl,-z,notext" RBENV_ROOT=/home/jcigar/rbenv rbenv install 1.9.3-p551

which fails as configure with the same "Unsupported relocation type 11 in non-PLT relocations"

I've copy/pasted the config.log at https://gist.github.com/silenius/52c0febc48e46d95435eafec9ff15054

this is on:

FreeBSD sandbox 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  amd64

with:

LLD 6.0.1 (FreeBSD 335540-1200005) (compatible with GNU linkers)
Comment 5 Gleb Popov freebsd_committer 2019-07-18 09:17:07 UTC
I don't get this problem anymore whem compiling TensorFlow. Not sure if it is fixed, or just some change on TensorFlow side, though.

Should we close this?
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2019-07-18 11:00:03 UTC
@Gleb Sure, please re-open if the issue becomes reproducible again