On Thu, Mar 20, 2008 at 10:21 AM, Lubomir Kundrak <lkundrak@xxxxxxxxxx> wrote: > Currently I have trouble to find out how did the sprintf symbol get into > tibbs' nazghul binary when none of object symbols it is linked from > refers to it. So don't worry about your packages, it might be the same > case. > > To others: If you can't find out why is your package on the list, don't > worry -- just send me the name. In case the number of the packages will > be bigger, then I must have done something wrong when generating the > list -- and in that case it won't be smart to send each package name to > the list. Feel free to mail me privately or via IRC. Here's some information that might help others. My package jlint is on the list. It compiles all source files with the standard %optflags, and the compiler issues no warnings about missing function declarations. Invoking 'nm -CD /usr/bin/jlint" lists __fprintf_chk, __printf_chk, __sprintf_chk ... and sprintf. Compiling by hand shows that all 4 symbols wind up in the jlint.o object file, even before linking. Compiling with "gcc -E" showed nothing out of the ordinary; the inline sprintf function that expands to a call to __sprintf_chk is there, all right, and before any invocations of sprintf. I had to dig through a disassembly of the object file to find the problem. That was fun. So gcc is failing to inline the "always inline" sprintf function in one place, jlint.cpp line 189. That particular invocation of sprintf looks just like several others, so I don't know why gcc did not inline it. Using "-Winline" doesn't help, because it doesn't warn about inline functions declared in system headers. Using "-Wsystem-headers -Winline" also prints no warnings, which I consider a gcc bug. I tried cranking "-finline-limit" up from the default of 600 all the way to 100000 without convincing gcc to inline that call. Bottom line: 1) As long as gcc can fail to inline calls, your script is going to emit false positives. 2) GCC refuses to report that it failed to inline the functions of interest. -- Jerry James http://loganjerry.googlepages.com/ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
