Hi,

I am Rahul. We have a complete software written out (with n other shared libraries maintained by various other teams). The shared libraries are loaded at run time by the main executable depending upon what feature user wants to run. All across our code, we are using printf and fprintf to print messages on the screen for the user. Now, we are adding a Graphical interface to our software and require that all such messages are displayed in a separate window inside that Graphical interface (whenever user is running in Graphical mode, else messages should be printed to screen only). For this, we need to overload printf and fprintf in our code. We have a combination of C and C++ code, as well as due to vast code base distributed across teams, it is not possible to replace printf/fprintf in all the code with some other function. So, what we did, we defined our own printf and fprintf functions that look something as follows -



Above function is defined in main executable (where our main() lies). So, above definition is loaded before fprintf from gcc library is loaded. I guess, no fprintf should be picked from libgcc now.
Above code works fine for following fprintf calls (that pass variable argument list to fprintf) -

fprintf (stdout,"This is a variable argument message - %s\n", "Rahul Jain");

However, for following fprintf call (that is not taking any variable arguments), it seems fprintf from libgcc is getting picked up as then print comes on the screen instead of our Graphical interface window -

fprintf (stdout,"This is a variable argument message - Rahul Jain\n");

I am not sure why this is happening. Is fprintf implemented as macro, such that it is working for case1 and not for case2. Can anybody help.

If we look at the way by which the loader resolves various symbols on loading an application, it does something as follows -

1. Load symbols defined and already binded in the executable
2. Load the shared library on which the application depends and then resolve the still undefined symbols in the application.

In my case, loader finds that fprintf/printf are already defined in my executable, so it should not lookup for this function while loading gcc shared library.

It seems to be the case as in case#1 (with variable argument list given to fprintf my own version is getting called). This does not happens for case #2 however.

I have also narrowed down that this issue comes with gcc 4.2.4 and not with gcc 3.4.2.

You can easily reproduce this issue by creating a printf.c and defining your version of fprintf in it and calling it from main (defined in main.c)

Does anyone know if any changes made between gcc 342 and gcc 424 that might be causing this issue, and if there is any workaround to it by some build time flags.

I would be really greateful if someone can help me and reply as soon as possible, we have a hight priority delivery item and is very critical... Really appreciate your help guys. Once again, thanks guys for your replies.

I have no way of checking that particular version of gcc just now, but...


Over the years there have been many, many (many) issues with optimization "improvements" from one version of gcc compilers to the next. In particular, there are many, many (many) ways that the printf family of statements have been optimized from time to time so that what you code is not necessarily what you get. See Footnote.

For example, here's an 'oldie but goodie' exposition from four or five years ago:

GCC GCC compiled source code is not always calling the functions you wrote in the source code

Maybe you can use some information there as a starting point for further investigation. Now that you know that others have had similar problems maybe you can search around. There may even be some hints in some of the release notes for versions of gcc between the one that gives you no problems and your current version. There may even be some command-line switches to inhibit that particular optimization (I haven't had the need to check, but I am interested in anything that you discover.)

What happens if you put -fno-builtin-fprintf and/or -fno-builtin-printf or, simply -fno-builtin on the command line?

Let us know what you find.


Regards,

Dave

Footnote:
Here's how I first realized that what you code is not necessarily what you get:

One acquaintance of mine, a very experienced programmer, tells me that I should always use putchar(xxx) to print out a single character rather than printf("%c",xxx), since printf has more overhead and, therefore, program size and speed would be better with putchar. Well I tested it and, guess what? With gcc the code is exactly the same! So, the supposed efficiency of using putchar() is an illusion, and, in my opinion, a completely superfluous detraction from my attempts in consistency in the visual presentation of my code.


Specifically to the point of this thread, that means that the linker doesn't even see the call to printf, since something else is generated by the compiler. I didn't think to investigate whether the substitution could be inhibited.


Bottom line: I know that some modern compilers (and particularly gcc) do the same with a string literal or other constants in printf statements: The call to printf may be transmogrified into something else entirely. IMPORTANT NOTE: I hope this is not taken as a challenge to discover anything about the effects of programmers' attempts to optimize code by using putchar instead of printf (or anything else). It can be seen that all of the slick tricks we learn right now may be ground into the dust (along with our other schoolboy illusions of supreme knowingfullness) by the next version of compiler.

Oh, well...

Hi Dave,

Thanks a lot .. Yeah .. it worked after I followed the directions as given in link suggested by you. It was a good learning experience. For now, I have used following flags to avoid gcc 424 doing these transformations -
-fno-builtin -fno-builtin-printf -fno-builtin-fprintf

But I guss , it is just a workaround and can break if gcc decides to do away with above compilation flags and force the transformation upon us

In that case, I would define all the versions of standard stream O/P functions (namely puts, fputs etc), but again that would not be a very good idea I suppose.

We have decided to go for pipe based approach to redirect out screen O/P to our graphical window when user runs in graphical mode (after we have delivered our immediate requirement )

Thanks for your efforts and reply (you saved me a lot of time)