Tag Archives: inline

When LD_PRELOAD doesn’t work

So, I recently had need to patch a binary. Due to some poor recording, I couldn’t rebuild the binary from source as I didn’t know what version of the source it was, and this was quite important. It looked like the source had been patched with one or more cherrypicked updates, and recompiled.

So, I was left with a quandary. I needed to change one instance of strcmp to strcasecmp, without breaking everything else and losing the exact patch(es) that had already been applied.

In the end I decided to use LD_PRELOAD and write a replacement for strcmp. It was only going to need to change on one specific search term, and so I could easily test the values passed in (using strcmp ironically) and replace strcmp with strcasecmp in this one specific instance.

However, after writing it, and LD_PRELOADing it, it just didn’t work. The function was there, because I could see debug coming out of it when other shared objects accessed strcmp, but the main executable itself, it just wasn’t having it.

A bit of checking, and some ltrace to prove it, and I found that when you use gcc with optimisation turned on, it inlines strcmp.

Now I know that strcmp is in a library so technically can’t be inlined, but gcc turns out to have its own version of various simple library functions, and substitutes them for the libc versions.

-fno-builtin as a gcc option stops this happening. But without that, you can’t use LD_PRELOAD to affect strcmp. Or several other functions.

Some gotchyas in porting from Visual C++ to g++

This article was originally published on the LGP Blog on Thursday, December 3rd, 2009

Todays technical article is going to go into a couple of issues that we have run across porting from Visual C++ to g++.

I will say right now that I am an application developer, I don’t know the fine details of how the inner workings of the compilers work, so some of this is merely an educated guess as to WHY the problem happens, but the effect and solution is correct.

The first issue for today is a fairly rare situation where g++, upon hitting a certain piece of code that builds fine under Visual C++, gives the helpful error message:

some/source/file.cpp:172: sorry, unimplemented: called from here

Now, I don’t know about you, but I find that error message singularly unhelpful. It took some time to run this one down the first time. It seems  that g++ and VC++ perform some symbol resolution in different passes to each other. Because what this message is saying is that ‘at line 172, you have tried to use __forceinline, or something you reference has a member function that has __forceinline in it, but I do not know what the thing is, so I cannot inline it’.

EDIT: g++ does not have the __forceinline keyword. There is an equivalent which does the same job however

#define __forceinline inline __attribute__((always_inline))

As VC++ has no problem with the same calls, the only real answer must be a compiler difference that allows VC++ to get away with something that g++ doesn’t. The simple solution is to just change __forceinline to inline and let the compiler inline as it sees fit. Otherwise, you will need to hunt down the exact problem and resolve the order of events for g++

The second issue I thought I would raise today is one that actually happens quite commonly on porting from Windows to Linux. This is the case of bad memory management.

On Windows, the way memory is allocated allows for a certain sloppiness in code. While HIGHLY unrecommended, this is the sort of thing that happens in Windows code all the time. The following is a highly simplified example of the problem.

char *str;
str=(char *)malloc(6)
strcpy(str,"hello");
free(str)
switch (str[0])
{
  ...
}

Now, as you can see here, the application uses the variable str right after it has been free()’d. On Windows it seems that this kind of thing can be gotten away with. The memory manager on Windows is highly unlikely to either assign this memory address somewhere else, or to mark it as unavailable. On Linux however, you will often find that this kind of code leads immediately to a segmentation fault.

The example above is highly simplified, but illustrates what some of the more complex segmentation faults we have seen boil down to.  If you see an error like this, which works on Windows and not on Linux, check your order of accessing. I know it sounds obvious, but it happens so often in commercial code that I feel it is worth stressing – free memory only when you have REALLY finished with it.