Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

The easiest way to see the source code that you're actually running from is to install the relevant debuginfo package, via debuginfo-install (part of the yum-utils package).

"strcpy" is actually implemented as part of glibc

# debuginfo-install glibc

Then look below /usr/src/debug.

strcpy is something of a special case. Given how commonly it occurs, it's a prime target for optimization. Looking at this on my F17 machine I see that the header files that declare strcpy also have a tangled web of preprocessor macros cases that can turn a call to strcpy into a more specialized function, depending on whether the source string is a string-literal of known size, and, if so, the length of that string.

To make things even more convoluted, note that strcpy is a prime target for compiler optimization, and that at any given callsite of strcpy the compiler might not have generated machine code that calls strcpy if it thinks it can do things faster. For example, looking at the sources of gcc on my F17 machine, I see in gcc/builtins.c:expand_builtin_strcpy that if gcc sees a "strcpy" call it can instead generate a movstr instruction when targetting CPUs that support it.

So it's worth invoking the compiler with -E to see the preprocessed output, and disassembling the generated machine code to see if strcpy is actually being called (e.g. by stepping through it in gdb and using the disassemble command within the function of interest).

The easiest way to see the source code that you're actually running from is to install the relevant debuginfo package, via debuginfo-install (part of the yum-utils package).

"strcpy" is actually implemented as part of glibc

# debuginfo-install glibc

Then look below /usr/src/debug.

strcpy is something of a special case. Given how commonly it occurs, it's a prime target for optimization. Looking at this on my F17 machine I see that the header files that declare strcpy also have a tangled web of preprocessor macros cases that can turn a call to strcpy into a more specialized function, depending on whether the source string is a string-literal of known size, and, if so, the length of that string.

To make things even more convoluted, note that strcpy is a prime target for compiler optimization, and that at any given callsite of strcpy the compiler might not have generated machine code that calls strcpy if it thinks it can do things faster. For example, looking at the sources of gcc on my F17 machine, I see in gcc/builtins.c:expand_builtin_strcpy gcc/builtins.c:expand_builtin_strcpy that if gcc sees a "strcpy" call it can instead generate a movstr instruction when targetting CPUs that support it.

So it's worth invoking the compiler with -E to see the preprocessed output, and disassembling the generated machine code to see if strcpy is actually being called (e.g. by stepping through it in gdb and using the disassemble command within the function of interest).