#2612 accepted enhancement

R_ARM_GOT_BREL relocation type unsupported

Reported by: Patrick Gauvin Owned by: Chris Johns
Priority: normal Milestone:
Component: lib/dl Version: 4.11
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

If a run-time loaded library contains global variables, its load fails because of an unsupported relocation type. The following is the dlerror message:

.text: Unsupported relocation type 26 in non-PLT relocations

After examining the library's object file, the relocation type for the symbol was determined to be R_ARM_GOT_BREL.

I will update the ticket with a small program that reproduces the error within a couple of days.

Attachments (1)

libdl-global-var-test.tar.gz (1.5 KB) - added by Patrick Gauvin on Feb 24, 2016 at 8:55:36 PM.

Download all attachments as: .zip

Change History (16)

comment:1 Changed on Feb 24, 2016 at 2:55:47 AM by Chris Johns

Status: newaccepted

I have located this reloc record in object files I have. I am not sure what is happening here are why it is appearing. In some code I am seeing:

000000bc  00001d19 R_ARM_BASE_PREL   00000000   _GLOBAL_OFFSET_TABLE_
000000c0  00001e1a R_ARM_GOT_BREL    00000004   hashtable_seed

and the code is:

https://github.com/akheron/jansson/blob/master/src/hashtable.c#L31

I this is strange. The fact a _GLOBAL_OFFSET_TABLE_ value is present is strange for RTEMS. We do not use a GOT.

Version 0, edited on Feb 24, 2016 at 2:55:47 AM by Chris Johns (next)

comment:2 Changed on Feb 24, 2016 at 5:39:13 AM by Chris Johns

Building this package from git for the Zynq does not seem to generate the reloc records. I am little confused by this.

comment:3 Changed on Feb 24, 2016 at 6:19:01 AM by Chris Johns

Is -fPIC being used when building the code?

comment:4 Changed on Feb 24, 2016 at 4:16:19 PM by Patrick Gauvin

Yes, -fPIC is used.

comment:5 Changed on Feb 24, 2016 at 4:45:42 PM by Joel Sherrill

Please try dropping the -fPIC option on anything you have it on. I don't think you need it anyway. Chris can confirm when it he wakes up.

comment:6 Changed on Feb 24, 2016 at 6:35:20 PM by Patrick Gauvin

Dropping -fPIC actually seems to resolve the dlopen failure.

I'll still post the example program and Makefile so the error can be reproduced.

With -fPIC:

Relocation section '.rel.text' at offset 0x96c contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000020  00001419 R_ARM_BASE_PREL   00000000   _GLOBAL_OFFSET_TABLE_
00000024  0000121a R_ARM_GOT_BREL    00000004   global_variable
00000040  00001419 R_ARM_BASE_PREL   00000000   _GLOBAL_OFFSET_TABLE_
00000044  0000121a R_ARM_GOT_BREL    00000004   global_variable

Without -fPIC:

Relocation section '.rel.text' at offset 0x904 contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000008  00000f2f R_ARM_THM_MOVW_AB 00000004   global_variable
0000000c  00000f30 R_ARM_THM_MOVT_AB 00000004   global_variable
00000024  00000f2f R_ARM_THM_MOVW_AB 00000004   global_variable
00000028  00000f30 R_ARM_THM_MOVT_AB 00000004   global_variable

comment:7 Changed on Feb 24, 2016 at 6:57:56 PM by Joel Sherrill

I am glad dropping the -fPIC got rid of the unsupported relocation record. I don't know why you would want to build with that for RTEMS. My gut is this is the resolution.

When Chris wakes up, he can make a ruling on what is the right thing long-term. It may or may not make sense to add support for this relocation record since we normally don't build with -fPIC. It is also possible that just adding an error message to say "don't build with -fPIC" when this record is seen isn't a bad idea. :)

Changed on Feb 24, 2016 at 8:55:36 PM by Patrick Gauvin

comment:8 Changed on Feb 24, 2016 at 8:59:19 PM by Patrick Gauvin

I'm glad you both caught that, it must have been leftover from porting our old Makefiles that were for Linux, and I just continued using it for the shared libraries.

Here are instructions for the attachment:

To generate code that causes the dlopen failure (omitting the override of LIB_OPTS will result in the test succeeding):

make clean all LIB_OPTS=-fPIC

Test with QEMU:

qemu-system-arm -m 256M -M xilinx-zynq-a9 -serial null \
  -serial mon:stdio -nographic -no-reboot \
  -kernel ./libdl-global-var-test.exe

One curiosity is that if the generated lib.o is loaded, rather than lib.so, there are unresolved symbols after the load. I haven't looked into why, but usually the plain object file is fine (the dl-01 test uses it, but also doesn't load global variables). This can be tested by changing line 15 of libdl-global-var-test.c to #define LIB_FILE_NAME "/lib.o". The tar file loaded at run-time contains both files, so no other changes are necessary.

Development environment (I forgot to include this in the original description):

  • RTEMS version: Branch "4.11", commit 2145853b009e939dfbe14869b710133f50500a26
  • RTEMS configure options: --target=arm-rtems4.11 --enable-rtemsbsp="xilinx_zynq_a9_qemu xilinx_zynq_zedboard" --enable-tests=samples --enable-posix --prefix=/home/patrick/development/rtems/4.11 --disable-networking
  • arm-rtems4.11-gcc --version
    arm-rtems4.11-gcc (GCC) 4.9.3 20150626 (RTEMS 4.11, RSB aa3fdad01a0dbc3cbfd7c49e1ea07ff1a585c0b9 (HEAD, origin/4.11, 4.11)-modified, Newlib 2.2.0.20150423)
    

comment:9 Changed on Feb 24, 2016 at 9:13:23 PM by Chris Johns

The -fPIC option is currently not supported. I have found -fPIC code when statically linked into the base image is fine so this shows the code is fine to run, it is just the need for this reloc record to be supported.

It may prove in time the -fPIC option is something useful. Patrick are you able to count the relocation records with -fPIC and without? I am wondering if an -fPIC build has fewer relocation records because the code is already position independent.

I will follow up your second issue about unresolved symbols once I get somewhere I can take a look.

comment:10 Changed on Feb 24, 2016 at 10:13:13 PM by Patrick Gauvin

There are 4 records in .rel.text both with and without -fPIC. That's not including debug records, but it looks like those are also the same in number.

comment:11 in reply to:  10 Changed on Feb 24, 2016 at 11:06:09 PM by Chris Johns

Replying to pggauvin:

There are 4 records in .rel.text both with and without -fPIC. That's not including debug records, but it looks like those are also the same in number.

Thanks. It looks like -fPIC does not give us anything extra.

I will leave the libdl code as is for now until the veneer support is added.

Joel, I am not in favor of a special error message. It opens up a can of worms by requiring us to catch every possible case. Now we know we will be able to support this issue a little better.

comment:12 Changed on Feb 25, 2016 at 1:46:33 AM by Joel Sherrill

It may make sense to have a separate utility that can check the integrity of the files and relocation records. Basically ensure it is OK and understandable by loader. I know of a precedence for that with a toolset I have used in the past. Was handy when oddities showed up and a handy thing to include in the build process in case something turned up.

comment:13 Changed on Feb 25, 2016 at 2:08:10 AM by Chris Johns

This means we need to keep the reloc records handled by the target in sync with a tool on the host.

What value does this provide? There are other options on gcc that can break the code we currently do not check for. I think suitable documentation will help as much.

comment:14 Changed on Feb 25, 2016 at 2:09:14 AM by Joel Sherrill

Just mentioning what I have seen done elsewhere. I know it is a maintenance burden and likely of little value since people will probably file a ticket before they run the tool. LOL

comment:15 Changed on Feb 25, 2016 at 2:13:15 AM by Chris Johns

We have the rtems-ld tool and that could do it. We would need to teach it about each arch and what is ok and what is not. I do hope our users run the code before they ship it as the target will tell them something is wrong. ;)

Note: See TracTickets for help on using tickets.