(I haven't posted a lot in the past couple years, except for git-cinnabar announcements. This is going to be a long one, hold tight)<\/p>\n
This is quite the cryptic title, isn't it? What is this all about? ELF (Executable and Linkable Format) is a file format used for binary files (e.g. executables, shared libraries, object files, and even core dumps) on some Unix systems (Linux, Solaris, BSD, etc.). A little over 12 years ago, I wrote a blog post about improving libxul startup I\/O by hacking the ELF format<\/a>. For context, libxul is the shared library, shipped with Firefox, that contains most of its code.<\/p>\n Let me spare you the read. Back then I was looking at I\/O patterns during Firefox startup on Linux<\/a>, and sought ways to reduce disk seeks that were related to loading libxul. One particular pattern was caused by relocations, and the way we alleviated it was through elfhack.<\/p>\n Relocations<\/a> are necessary in order for executables to work when they are loaded in memory at a location that is not always the same (because of e.g. ASLR<\/a>). Applying them requires reading the section containing the relocations, and adjusting the pieces of code or data that are described by the relocations. When the relocation section is very large (and that was the case on libxul back then, and more so now), that means going back and forth (via disk seeks) between the relocation section and the pieces to adjust.<\/p>\n Shortly after the aforementioned blog post, the elfhack tool was born and made its way into the Firefox code base<\/a>.<\/p>\n The main idea behind elfhack was to reduce the size of the relocation section. How? By storing it in a more compact form<\/a>. But how? By taking the executable apart, rewriting its relocation section, injecting code to apply those relocations, moving sections around, and adjusting the ELF program header, section header, section table, and string table accordingly. I will spare you the gory details (especially the part about splitting segments or the hack to use .bss section as a temporary Global Offset Table). Elfhack itself is essentially a minimalist linker that works on already linked executables. That<\/a> has<\/a> caused<\/a> us<\/a> a<\/a> number<\/a> of<\/a> issues<\/a> over<\/a> the<\/a> years<\/a> (and<\/a> much<\/a> more<\/a>). In fact, it's known not to work on binaries created with lld (the linker from the LLVM project) because the way lld lays things out does not provide space for the tricks we pull (although it seems to be working with the latest version of lld. But who knows what will happen with next version).<\/p>\n Hindsight is 20\/20, and if I were to redo it, I'd take a different route. Wait, I'm actually kind of doing that! But let me fill you in with what happened in the past 12 years, first.<\/p>\n In 2014, Chrome started using a similar-ish approach for Android on ARM<\/a> with an even more compact format, compared to the crude packing elfhack was doing. Instead of injecting initialization code in the executable, it would use a custom dynamic loader\/linker to handle the packed relocations<\/a> (that loader\/linker was forked from the one in the Android NDK<\/a>, which solved similar problems to what our own custom linker had<\/a>, but that's another story).<\/p>\n That approach eventually made its way into Android itself<\/a>, in 2015, with support from the dynamic loader in bionic<\/a> (the Android libc), and later support for emitting those packed relocations was added to lld<\/a> in October 2017. Interestingly, the packer added to lld created smaller packed relocations than the packer in Android (for the same format).<\/p>\n Shortly after bionic got its native packed relocation support, a conversation started on the gnu-gabi mailing list<\/a> related to the general problem of relocations representing a large portion of Position Independent Executable. What we observed on a shared library had started to creep into programs as well because PIE binaries started to be prominent around that time, with some compilers and linkers starting to default to that for hardening reasons. Both Chrome's and Firefox prior art were mentioned<\/a>. This was April 2017.<\/p>\n A few months went by, and a simpler format was put forward<\/a>, with great results, which led to, a few days later, a formal proposal for RELR relocations in the Generic System V Application Binary Interface<\/a>.<\/p>\n Shortly after the proposal, Android got experimental support for it<\/a>, and a few months later, in July 2018, lld gained experimental support as well<\/a>.<\/p>\n The Linux kernel got support for it too<\/a>, for KASLR relocations, but for arm64 only (I suppose this was for Android kernels. It still is the only architecture it has support for to this day).<\/p>\n GNU binutils gained support for the proposal<\/a> (via a Lld thereafter got support for the same flag as binutils's<\/a>, with the same side effect of adding a version dependency on Elfhack was updated to use the format from the proposal<\/a> at the very end of 2021 (or rather, close enough to that format<\/a>). More recently (as in, two months ago), support for the Which (finally) brings us to the next step, and the meat of this post.<\/p>\n It's actually still too early for that. The Firefox binaries Mozilla provides need to run on a broad variety of systems, including many that don't support those new packed relocations. That includes Android systems older than Red Velvet Cake (11), and not necessarily very old desktop systems.<\/p>\n Android Pie (9) shipped with experimental, but incompatible, support for the same packed relocation format, but using different constants. Hacking the PT_DYNAMIC segment (the segment containing metadata for dynamic linking) for compatibility with all Android versions >= 9 would technically be possible, but again, Mozilla needs to support even older versions of Android.<\/p>\n There comes the idea behind what I've now called To some extent, that sounds similar to what elfhack does, doesn't it? But elfhack packs the relocations itself. And because its input is a fully linked binary, it has to do complex things that we know don't always work reliably.<\/p>\n In the past few years, an idea was floating in the back of my mind to change elfhack to start off a relocatable binary (also known as partially linked). It would then rewrite the sections it needs to, and invoke the linker to link that to its initialization code and produce the final binary. That would theoretically avoid all the kinds of problems we've hit, and work more reliably with lld.<\/p>\n The idea I've toyed with more recently, though, is even simpler: Use the My first attempts were with a small executable, and linking with lld's older I quickly got something working on a Debian Bullseye system (using an older glibc that doesn't support the packed relocations). Here's how it goes:<\/p>\n This is a minimal Hello world program that contains a relative relocation: the Compiling just this without which is more user-friendly than a plain crash.<\/p>\n At this point, what do we want? Well, we want to apply the relocations ourselves, as early as possible. The first thing that will run in an executable is its "entry point", that defaults to Here's our own entry point. It will start by calling the "real" initialization function we forward declare here. Let's see if that actually works. Let's add the following temporarily and see how things go.<\/p>\n Running the program now yields:<\/p>\n There we go, we've executed code before anything relies on the relative relocations being applied. By the way, adding functions calls like this printf, that early, with elfhack, was an interesting challenge. This is pleasantly much simpler.<\/p>\n Let's replace that The defines are there because older systems don't have them in link.h. Now we're ready for the real work:<\/p>\n It's all kind of boring here. We scan the PT_DYNAMIC segment to get the location and size of the packed relocations section, and then read and apply them.<\/p>\n And does it work?<\/p>\n It does! Mission accomplished? If only...<\/p>\n Let's try running this same binary on a system with a more recent glibc:<\/p>\n Oh come on! Yes, glibc insists that when the PT_DYNAMIC segment contains these types of relocations, the binary must have that symbol version dependency. That same symbol version dependency we need to avoid in order to work on older systems. I have no idea why the glibc developers went all their way to prevent that. Someone even asked when this was all at the patch stage, with no answer<\/a>.<\/p>\n We'll figure out a workaround later. Let's use Oops. Well, that actually didn't happen when I was first testing, but for the purpose of this post, I didn't want to touch this topic before strictly necessary. Because we're now running on a system that does support the packed relocations, when our initialization code is reached, relocations are already applied, and we're applying them again. That overcompensates every relocated address, and leads to accesses to unmapped memory.<\/p>\n But how can we know whether relocations were applied? Well, conveniently, the address of a function, from within that function, doesn't need a relative relocation to be known. That's one half. The other half requires "something" that uses a relative relocation to know that same address. We insert this before Because it's a global variable that points to the address of the function, it requires a relocation. And because the function is static and in the compilation unit, it needs a relative relocation, not one that would require symbol resolution.<\/p>\n Now we can add this at the beginning of And we're done. This works:<\/p>\n Unfortunately, we're back to square one on an older system:<\/p>\n And here we go again, having to post-process a binary. So what do we need this time around? Well, starting from a binary linked with How do we do that? Open the file, find the PT_DYNAMIC segment, scan it, overwrite a few tags with a different value, and done. Damn, that's much less work than everything elfhack was doing. I will spare you the code required to do that. Heck, that can trivially be done in a hex editor. Hey, you know what? That would actually be less stuff to write here than ELF parsing code, and would still allow you to follow at home.<\/p>\n Let's start from that binary we built earlier with We now have a In that segment, each block of 16 bytes (assuming a 64-bits system) stores a 8-byte tag and a 8-byte value. We want to change the (got lucky a bit here, not matching anywhere else than in the tag)<\/p>\n Let's set an extra arbitrary high-ish bit.<\/p>\n This went well, let's do it for real.<\/p>\n Let me tell you I'm glad we're in 2023, because these objcopy options we just used didn't exist 12+ years ago.<\/p>\n So, how did it go?<\/p>\n Uh oh. Well duh, we didn't change the code that applies the relocations, so it can't find the packed relocation section.<\/p>\n Let's edit the loop to use this:<\/p>\n And start over:<\/p>\n Copy over to the newer system, and try:<\/p>\n Flawless victory<\/a>. We now have a binary that works on both old and new systems, using packed relocations created by the linker, and barely post-processing the binary (and we don't need that Okay, so while we're here, we'd rather use You know what, we might as well learn new things. Objcopy is nice, but as I was starting to write this section, I figured it was going to be annoying to do in the same style as above.<\/p>\n Have you heard of GNU poke<\/a>? I saw a presentation about it at FOSDEM 2023<\/a>, and haven't had the occasion to try it, I guess this is the day to do that. We'll be using GNU poke 3.2 (latest version as of writing).<\/p>\n Of course, that version doesn't contain the necessary bits. But this is Free Software, right? After a<\/a> few<\/a> patches<\/a>, we're all set.<\/p>\n Let's get the section containing the symbol version information. It starts with a Verneed header.<\/p>\n Bingo. Now let's scan the two (per And the second one, that This is it. This is the symbol version we want to get rid of. We could go on by adjusting We could stop here and go back to the Gah, that seemed straightforward. It turns out This time, this is because poke is actually validating the tag values, which is both a blessing and a curse. It can avoid shooting yourself in the foot (after all, we're setting a non-existing value), but also hinder getting things done (because before I actually got here, many of the Let's make poke's validator know about the values we're about to set:<\/p>\n And it works on the newer system too!<\/p>\n Let's set up a new testcase, using a shared library:<\/p>\n So now, it should work, right?<\/p>\n Oops. What's going on?<\/p>\n Side note: it looks like we'll also need to change some section types if we want to keep tools like gdb happy.<\/p>\nElfhack to the rescue<\/h2>\n
Android packed relocations<\/h2>\n
The road to standardization<\/h2>\n
More widespread availability<\/h2>\n
-z pack-relative-relocs<\/code> flag) at the end of 2021, and glibc eventually caught up<\/a> in 2022, and this shipped respectively in binutils 2.38 and glibc 2.36. These versions should now have reached most latest releases of major Linux distros.<\/p>\nGLIBC_ABI_DT_RELR<\/code>, to avoid crashes when running executables with packed relocations against an older glibc.<\/p>\nWhat about Firefox?<\/h2>\n
-z pack-relative-relocs<\/code> flag was added<\/a>, so that when building Firefox against a recent enough glibc and with a recent enough linker, it will use that instead of elfhack automatically. This means in some cases, Firefox packages in Linux distros will be using those relocations (for instance, that's the case since Firefox 116 in Debian unstable).<\/p>\nRetiring Elfhack<\/h2>\n
relrhack<\/code>: injecting code that can apply the packed relocations created by the linker if the system dynamic loader hasn't.<\/p>\n-z pack-relative-relocs<\/code> linker support, and add the initialization code on the linker command line so that it does everything in one go. We're at this sweet spot in time where we can actually start doing this.<\/p>\nTesting the idea<\/h2>\n
--pack-dyn-relocs=relr<\/code> flag, which does the same as -z pack-relative-relocs<\/code> but skips adding the GLIBC_ABI_DT_RELR<\/code> version dependency. That allowed to avoid having to do post-processing of the binary in this first experimentation step.<\/p>\n\/\/ Compile with: clang -fuse-ld=lld -Wl,--pack-dyn-relocs=relr,--entry=my_start,-z,norelro -o relr-test\n#include <stdio.h>\n\nchar *helloworld[] = {"Hello, world"};\n\nint main(void) {\n printf("%s\\n", helloworld[0]);\n return 0;\n}<\/code><\/pre>\nhelloworld<\/code> variable is an array of pointers, and those pointers need to be relocated. Optimizations would get rid of the array but we don't enable optimizations specifically for that. We also disable "Relocation Read-Only", which is a protection that makes the dynamic loader relocated sections read-only after it's done applying relocations. That would prevent us from applying the missing relocations on our own. We're just testing, we'll deal with that later.<\/p>\n--entry=my_start<\/code> (because we haven't defined that yet), and running it yields a segmentation fault. We don't even reach main<\/code> because there actually is an initialization function section that runs before that, and its location, defined in the .init_array<\/code> section, is behind a relative relocation, which --pack-dyn-relocs=relr<\/code> packed. This is exactly why -z pack-relative-relocs<\/code> adds a dependency on a symbol version that doesn't exist in older glibcs. With that flag, the error becomes:<\/p>\n\/lib\/x86_64-linux-gnu\/libc.so.6: version `GLIBC_ABI_DT_RELR' not found<\/code><\/pre>\n_start<\/code> (provided by the C runtime, aka CRT). As hinted in the code snippet above, we can set our own with --entry<\/code>.<\/p>\nstatic void real_init();\nextern void _start();\n\nvoid my_start() {\n real_init();\n _start();\n}<\/code><\/pre>\nvoid real_init() {\n printf("Early Hello world\\n");\n}<\/code><\/pre>\n$ .\/relr-test\nEarly Hello world\nSegmentation fault<\/code><\/pre>\nApplying the relocations for real<\/h2>\n
real_init<\/code> function with some boilerplate for the upcoming real real_init<\/code>:<\/p>\n#include <link.h>\n\n#ifndef DT_RELRSZ\n#define DT_RELRSZ 35\n#endif\n#ifndef DT_RELR\n#define DT_RELR 36\n#endif\n\nextern ElfW(Dyn) _DYNAMIC[];\nextern ElfW(Ehdr) __executable_start;<\/code><\/pre>\n_DYNAMIC<\/code> is a symbol that gives access to the PT_DYNAMIC segment at runtime, and the __executable_start<\/code> symbol gives access to the base address of the program, which non-relocated addresses in the binary are relative to.<\/p>\nvoid real_init() {\n \/\/ Find the relocations section.\n ElfW(Addr) relr;\n ElfW(Word) size = 0;\n for (ElfW(Dyn) *dyn = _DYNAMIC; dyn->d_tag != DT_NULL; dyn++) {\n if (dyn->d_tag == DT_RELR) {\n relr = dyn->d_un.d_ptr;\n }\n if (dyn->d_tag == DT_RELRSZ) {\n size = dyn->d_un.d_val;\n }\n }\n uintptr_t elf_header = (uintptr_t)&__executable_start;\n\n \/\/ Apply the relocations.\n ElfW(Addr) *ptr, *start, *end;\n start = (ElfW(Addr) *)(elf_header + relr);\n end = (ElfW(Addr) *)(elf_header + relr + size);\n for (ElfW(Addr) *entry = start; entry < end; entry++) {\n if ((*entry & 1) == 0) {\n ptr = (ElfW(Addr) *)(elf_header + *entry);\n *ptr += elf_header;\n } else {\n size_t remaining = 8 * sizeof(ElfW(Addr)) - 1;\n ElfW(Addr) bits = *entry;\n do {\n bits >>= 1;\n remaining--;\n ptr++;\n if (bits & 1) {\n *ptr += elf_header;\n }\n } while (bits);\n ptr += remaining;\n }\n }\n}<\/code><\/pre>\n$ .\/relr-test\nHello, world<\/code><\/pre>\nThe devil is in the details<\/h2>\n
$ .\/relr-test \n.\/relr-test: error while loading shared libraries: .\/relr-test: DT_RELR without GLIBC_ABI_DT_RELR dependency<\/code><\/pre>\n-Wl,-z,pack-relative-relocs<\/code> for now and see how it goes.<\/p>\n$ .\/relr-test \nSegmentation fault<\/code><\/pre>\nreal_init<\/code>, but after its forward declaration:<\/p>\nvoid (*__real_init)() = real_init;<\/code><\/pre>\nreal_init<\/code>:<\/p>\n \/\/ Don't apply relocations when the dynamic loader has applied them already.\n if (__real_init == real_init) {\n return;\n }<\/code><\/pre>\n$ .\/relr-test \nHello, world<\/code><\/pre>\n$ .\/relr-test \n.\/relr-test: \/lib\/x86_64-linux-gnu\/libc.so.6: version `GLIBC_ABI_DT_RELR' not found (required by .\/relr-test)<\/code><\/pre>\nHacking the ELF format, again<\/h2>\n
--pack-dyn-relocs=relr<\/code>, we need to avoid the "DT_RELR without GLIBC_ABI_DT_RELR" check. If we change the PT_DYNAMIC segment such that it doesn't contain DT_RELR-related tags, the error will be avoided. Sadly, that means we'll always apply relocations ourselves, but so be it.<\/p>\n--pack-dyn-relocs=relr<\/code>.<\/p>\n$ objcopy --dump-section .dynamic=dyn relr-test<\/code><\/pre>\ndyn<\/code> file with the contents of the PT_DYNAMIC segment.<\/p>\nDT_RELR<\/code>, DT_RELRSZ<\/code> and DT_RELRENT<\/code> tags. Their hex value are, respectively, 0x24, 0x23 and 0x25.<\/p>\n$ xxd dyn | grep 2[345]00\n00000060: 2400 0000 0000 0000 6804 0000 0000 0000 $.......h.......\n00000070: 2300 0000 0000 0000 1000 0000 0000 0000 #...............\n00000080: 2500 0000 0000 0000 0800 0000 0000 0000 %...............<\/code><\/pre>\n$ xxd dyn | sed -n '\/: 2[345]00\/s\/ 0000\/ 0080\/p'\n00000060: 2400 0080 0000 0000 6804 0000 0000 0000 $.......h.......\n00000070: 2300 0080 0000 0000 1000 0000 0000 0000 #...............\n00000080: 2500 0080 0000 0000 0800 0000 0000 0000 %...............<\/code><\/pre>\n$ xxd dyn | sed '\/: 2[345]00\/s\/ 0000\/ 0080\/' | xxd -r > dyn.new\n$ objcopy --update-section .dynamic=dyn.new relr-test<\/code><\/pre>\n$ .\/relr-test \nSegmentation fault<\/code><\/pre>\n if (dyn->d_tag == (DT_RELR | 0x80000000)) {\n relr = dyn->d_un.d_ptr;\n }\n if (dyn->d_tag == (DT_RELRSZ | 0x80000000)) {\n size = dyn->d_un.d_val;\n }<\/code><\/pre>\n$ clang -fuse-ld=lld -Wl,--pack-dyn-relocs=relr,--entry=my_start,-z,norelro -o relr-test relr-test.c\n$ objcopy --dump-section .dynamic=dyn relr-test\n$ xxd dyn | sed '\/: 2[345]00\/s\/ 0000\/ 0080\/' | xxd -r > dyn.new\n$ objcopy --update-section .dynamic=dyn.new relr-test\n$ .\/relr-test\nHello, world<\/code><\/pre>\n$ .\/relr-test\nHello, world<\/code><\/pre>\n if (__real_init == real_init)<\/code> anymore).<\/p>\nGeneralizing a little<\/h2>\n
-z packed-relative-relocs<\/code> because it works across more linkers, so we need to get rid of that GLIBC_ABI_DT_RELR<\/code> symbol version dependency it adds, in order for the output to be more or less equivalent to what --pack-dyn-relocs=relr<\/code> would produce.<\/p>\n$ clang -fuse-ld=lld -Wl,-z,pack-relative-relocs,--entry=my_start,-z,norelro -o relr-test relr-test.c<\/code><\/pre>\n$ git clone https:\/\/git.savannah.gnu.org\/git\/poke\/poke-elf\n$ POKE_LOAD_PATH=poke-elf poke relr-test\n(poke) load elf\n(poke) var elf = Elf64_File @ 0#B<\/code><\/pre>\n(poke) var section = elf.get_sections_by_type(ELF_SHT_GNU_VERNEED)[0]\n(poke) var verneed = Elf_Verneed @ section.sh_offset\n(poke) verneed\nElf_Verneed {vn_version=1UH,vn_cnt=2UH,vn_file=110U,vn_aux=16U,vn_next=0U}<\/code><\/pre>\nvn_file<\/code> identifies the library file expected to contain those vn_cnt<\/code> versions. Let's check this is about the libc. The section's sh_link<\/code> will tell us which entry of the section header (shdr<\/code>) corresponds to the string table that vn_file<\/code> points into.<\/p>\n(poke) var strtab = elf.shdr[section.sh_link].sh_offset\n(poke) string @ strtab + verneed.vn_file#B\n"libc.so.6"<\/code><\/pre>\nvn_cnt<\/code>) Vernaux entries that the Verneed header points to via vn_aux<\/code>. The first one:<\/p>\n(poke) var off = section.sh_offset + verneed.vn_aux#B\n(poke) var aux = Elf_Vernaux @ off\n(poke) aux\nElf_Vernaux {vna_hash=157882997U,vna_flags=0UH,vna_other=2UH,vna_name=120U,vna_next=16U}\n(poke) string @ strtab + aux.vna_name#B\n"GLIBC_2.2.5"<\/code><\/pre>\nvna_next<\/code> points to.<\/p>\n(poke) var off = off + aux.vna_next#B\n(poke) var aux2 = Elf_Vernaux @ off\n(poke) aux2\nElf_Vernaux {vna_hash=16584258U,vna_flags=0UH,vna_other=3UH,vna_name=132U,vna_next=0U}\n(poke) string @ strtab + aux2.vna_name#B\n"GLIBC_ABI_DT_RELR"<\/code><\/pre>\nvna_next<\/code> in the first entry, and reducing vn_cnt<\/code> in the header, but forward thinking to automating this for binaries that may contain more than two symbol versions from more than one dependency, it's just simpler to pretend this version is a repeat of the previous one. So we copy all its fields, except vna_next<\/code>.<\/p>\n(poke) aux2.vna_hash = aux.vna_hash \n(poke) aux2.vna_flags = aux.vna_flags \n(poke) aux2.vna_other = aux.vna_other\n(poke) aux2.vna_name = aux.vna_name<\/code><\/pre>\nobjcopy<\/code>\/xxd<\/code> way of adjusting the PT_DYNAMIC segment, but while we're in poke, it can't hurt to try to do the adjustement with it.<\/p>\n(poke) var dyn = elf.get_sections_by_type(ELF_SHT_DYNAMIC)[0]\n(poke) var dyn = Elf64_Dyn[dyn.sh_size \/ dyn.sh_entsize] @ dyn.sh_offset\n(poke) for (d in dyn) if (d.d_tag in [ELF_DT_RELR,ELF_DT_RELRSZ,ELF_DT_RELRENT]) d.d_tag |= 0x80000000L\n<stdin>:1:20: error: invalid operand in expression\n<\/stdin><stdin>:1:20: error: expected uint<32>, got Elf64_Sxword<\/code><\/pre>\nin<\/code> is not lenient about integer types. Let's just use the plain values.<\/p>\n(poke) for (d in dyn) if (d.d_tag in [0x23L,0x24L,0x25L]) d.d_tag |= 0x80000000L\nunhandled constraint violation exception\nfailed expression\n elf_config.check_enum ("dynamic-tag-typ elf_mach, d_tag)\nin field Elf64_Dyn.d_tag<\/code><\/pre>\nd_tag<\/code> values in the binary straight out of the linker weren't even supported).<\/p>\n(poke) for (n in [0x23L,0x24L,0x25L]) elf_config.add_enum :class "dynamic-tag-types" :entries [Elf_Config_UInt { value = 0x80000000L | n }]\n(poke) for (d in dyn) if (d.d_tag in [0x23L,0x24L,0x25L]) d.d_tag |= 0x80000000L\n(poke) .exit\n$ .\/relr-test\nHello, world<\/code><\/pre>\nRepeating for a shared library<\/h2>\n
\n
main<\/code> function to relr_test<\/code>.<\/li>\nclang -fuse-ld=lld -Wl,--pack-dyn-relocs=relr,--entry=my_start,-z,norelro -fPIC -shared -o librelr-test.so<\/code><\/li>\n\/\/ Compile with: clang -o relr-test -L. -lrelr-test -Wl,-rpath,'$ORIGIN'\nextern int relr_test(void);\n\nint main(void) {\n return relr_test();\n}<\/code><\/pre>\n\n
librelr-test.so<\/code> file.<\/li>\n<\/ul>\n$ .\/relr-test\nSegmentation fault<\/code><\/pre>\n$ gdb -q -ex run -ex backtrace -ex detach -ex quit .\/relr-test\nReading symbols from .\/relr-test...\n(No debugging symbols found in .\/relr-test)\nStarting program: \/relr-test \nBFD: \/librelr-test.so: unknown type [0x13] section `.relr.dyn'\nwarning: `\/librelr-test.so': Shared library architecture unknown is not compatible with target architecture i386:x86-64.\n\nProgram received signal SIGSEGV, Segmentation fault.\n0x00000000000016c0 in ?? ()\n#0 0x00000000000016c0 in ?? ()\n#1 0x00007ffff7fe1fe2 in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffdfc8, \n env=env@entry=0x7fffffffdfd8) at dl-init.c:72\n#2 0x00007ffff7fe20e9 in call_init (env=0x7fffffffdfd8, argv=0x7fffffffdfc8, argc=1, l=<\/optimized><optimized out>) at dl-init.c:30\n#3 _dl_init (main_map=0x7ffff7ffe180, argc=1, argv=0x7fffffffdfc8, env=0x7fffffffdfd8) at dl-init.c:119\n#4 0x00007ffff7fd30ca in _dl_start_user () from \/lib64\/ld-linux-x86-64.so.2\n#5 0x0000000000000001 in ?? ()\n#6 0x00007fffffffe236 in ?? ()\n#7 0x0000000000000000 in ?? ()\nDetaching from program: \/relr-test, process 3104868\n[Inferior 1 (process 3104868) detached]<\/code><\/pre>\n