CODEWITHSUNDEEP
gccdllmingw-w64relocation
kktsuri
kktsuri

Reputation: 453

Using Linker Symbol from C++ code as a fixed constant (NOT relocated) in a shared library (DLL)

Sorry if the title is not very clear. I am using MinGW with GCC 6.3.0 to build a x86 32-bit DLL on Windows (so far). I'll spare you the details why I need hacky offsets amongst its sections accessible from code, so please do not ask if it's useful or not (because I don't want to bother explaining that).

So, if I can get the following testcase to work, I'm good. Here's my problem:

In a C++ file, I want to access a linker symbol as an absolute numeric value, not relocated, directly. Remember that I am building a 32-bit DLL which requires a .reloc section for relocations, but in this case I do NOT want relocation, in fact a relocation would screw it up completely.

Here's an example: retrieve the offset of say __imp__MessageBoxW@16 relative to __IAT_start__, in case you don't know what they are, __imp__MessageBoxW@16 is the relocated pointer to the actual function at runtime, and __IAT_start__ is a linker symbol in the default script file. Here's where it is defined:

.idata BLOCK(__section_alignment__) :
{
    /* This cannot currently be handled with grouped sections.
    See pe.em:sort_sections.  */
    KEEP (SORT(*)(.idata$2))
    KEEP (SORT(*)(.idata$3))
    /* These zeroes mark the end of the import list.  */
    LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
    KEEP (SORT(*)(.idata$4))
    __IAT_start__ = .;
    KEEP (SORT(*)(.idata$5))
    __IAT_end__ = .;
    KEEP (SORT(*)(.idata$6))
    KEEP (SORT(*)(.idata$7))
}

So far, no problem. Because GAS doesn't allow me to "subtract" two externally defined symbols (both symbols are defined in the linker), I have to define the symbol in the linker script, so at the end of the linker script I have this:

test_symbol = ABSOLUTE("__imp__MessageBoxW@16" - __IAT_start__);

Then in C++ I use this little inline asm to retrieve this relative difference which is supposed to be a fixed value once linked:

asm("movl $test_symbol, %0":"=r"(var));

Now var should contain that fixed number right? Wrong!

Because test_symbol is an "undefined" symbol as far as the assembler is concerned, it makes it relocated. Or I don't know why, but I tried so many things to force it to be an "absolute constant value symbol" instead of a "relocated symbol" to no avail. Even editing the linker script with many things like LD_FEATURE("SANE_EXPR") and others, doesn't work at all.

Its value is correct only if the DLL does not get relocated.

You see, either GNU LD or the assembler adds an entry in the .reloc section for that movl instruction, which is WRONG!

Is there a way to force it to treat an external/undefined symbol as a fixed CONSTANT and apply no relocation to it whatsoever? Basically, omit it from the .reloc section.

I am going crazy with this, please tell me there's something easy I overlooked, I searched for hours!

In other words, is there a way to use a Linker Symbol from within inline asm/C++ without having it relocated whatsoever? No entry to the .reloc section or anything, basically same as a constant like $1234. So if a DLL gets loaded into another base address, that constant would be the same everytime.

UPDATE: I forgot about this question but decided to bring an update, since it seems it's likely not possible as nobody even commented. For anyone else in the same boat as me, I presume this is a limitation of the COFF object format itself. In other words, external symbols are implicitly relocated, and it doesn't seem there's a way against this.

I didn't "fix" it the way I wanted, I did it in a very hacky way though. If anyone is interested, here's my ugly "hack":

First I put a special "custom" instruction in the inline assembly where I reference this external symbol from C++. This "custom" instruction holds a placeholder instruction that grabs the symbol (normal x86 asm instruction with a dummy constant, e.g. 1234) and a way to identify it. Then let GCC generate the assembly files (.S files), then I parse the assembly with a simple script and when I find that "custom" instruction I insert a label for the linker (make it .global) and at the same time add a directive to a custom "on-the-fly" generated linker script that gets included from my main linker script at the end.

This places data in a temporary section in the resulting DLL with absolute offsets to the custom instruction that I need, but without relocation.

Next, I parse the binary DLL itself, in particular that temporary section I added with all this hack. I take the offsets from there, convert them to file offsets, and modify the DLL's .text section directly where those offsets point (remember those placeholder instructions? it is replacing their immediate constants 1234 with the respective value from the linker's non-relocated constant). Then I strip the temporary section from the DLL, and it's done. Of course, all of this is done automatically by a helper program and script

It's an insane hack, but it works and it's fully automatic now that I got it going. If my assumption is correct that COFF doesn't support non-relocated external symbols, then it's really the only way to use linker constants from C++ without them being relocated, which would be a disaster.

Upvotes: 3

Views: 896

Answers (1)

Marcelo Pacheco
Marcelo Pacheco

Reputation: 276

__asm__ volatile(
"mov %0, offset symbol_name\n"
 : "+x"(load_symbol_value_here));

I'm doing baremetal programming where there is no run time relocation, so it works perfectly for me (I'm generating PIE code, using only X86_64 RIP relative addressing), but I'm not so sure what ld will do in your case.

Upvotes: 0

Related Questions