On Tue, Apr 13, 2010 at 09:01:16AM +0200, Duncan Sands wrote:> Hi Jack, > >> bash-3.2$ gcc-4 hello.c -S -O1 -o - -fplugin=./dragonegg.so >> cc1: error: Cannot load plugin ./dragonegg.so >> dlopen(./dragonegg.so, 10): Symbol not found: _classify_argument > > looks like you forgot to apply the i386_static.diff patch to gcc. > > Ciao, > > Duncan.Duncan, Doesn't i386_static.diff represent a violation of... https://www.securecoding.cert.org/confluence/display/seccode/DCL36-C.+Do+not+declare+an+identifier+with+conflicting+linkage+classifications since it first declares a function as extern and then redefines it locally? Jack
Hi Jack,> Doesn't i386_static.diff represent a violation of... > > https://www.securecoding.cert.org/confluence/display/seccode/DCL36-C.+Do+not+declare+an+identifier+with+conflicting+linkage+classifications > > since it first declares a function as extern and then > redefines it locally?I don't think so. "Redefines it locally" is not the same as giving it internal linkage. By the way, if it was a problem, how would header files work? It is common practice to declare a function in a header file, eg "header.h" and then include that header file in the file defining the function, eg "body.c". For example: header.h: void foo(void); body.c: #include "header.h" void foo(void) { ... } After the preprocessor runs, you get: body.i void foo(void); void foo(void) { ... } which is equivalent to what you get from my patch. If this results in undefined behavior, then a lot of software out there is broken! Note that AFAIK void foo(void); and extern void foo(void); are equivalent. Ciao, Duncan.
On Tue, Apr 13, 2010 at 04:06:45PM +0200, Duncan Sands wrote:> Hi Jack, > >> Doesn't i386_static.diff represent a violation of... >> >> https://www.securecoding.cert.org/confluence/display/seccode/DCL36-C.+Do+not+declare+an+identifier+with+conflicting+linkage+classifications >> >> since it first declares a function as extern and then >> redefines it locally? > > I don't think so. "Redefines it locally" is not the same as giving it internal > linkage. By the way, if it was a problem, how would header files work? It is > common practice to declare a function in a header file, eg "header.h" and then > include that header file in the file defining the function, eg "body.c". For > example: > > header.h: > > void foo(void); > > body.c: > > #include "header.h" > > void foo(void) { > ... > } > > After the preprocessor runs, you get: > > body.i > > void foo(void); > > void foo(void) { > ... > } > > which is equivalent to what you get from my patch. If this results in > undefined behavior, then a lot of software out there is broken! > > Note that AFAIK > > void foo(void); > > and > > extern void foo(void); > > are equivalent. > > Ciao, > > Duncan.Duncan, Can't we drop the extern from the patch and use something like... void foo(void) __attribute__(externally_visible); as described in http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html? Jack