On 5/20/2011 9:48 PM, Darren Reed wrote: > Whilst trying to compile dladm with "-g", I received this error: > ... > Undefined first referenced > symbol in file > brlsum_t_is_too_large dladm.o > brsum_t_is_too_large dladm.o > ld: fatal: symbol referencing errors. No output written to dladm > > Looking in dladm.c, I find this: > > +#ifndef lint > + /* This is a compile-time assertion; optimizer normally fixes > this */ > + extern void brlsum_t_is_too_large(void); > + > + if (sizeof (*brlsum)> sizeof (state->ls_prevstats)) > + brlsum_t_is_too_large(); > +#endif > > ... given that this prohibits compiling with -g, > can someone explain why this belongs in dladm.c?
It's an old trick. Normally, the values in the test evaluate at compile time, and the test is false. The compiler's optimizer removes the 'if' statement (because it resolves to a constant) and completely removes the call. Because the call isn't included in the object file, it links and works fine. If someone modifies brlsum_t to add new fields or removes something from state->ls_prevstats, so that the 'if' statement evaluates to true, then the compiler creates a call to that intentionally-undefined function, and that breaks the build -- on purpose. The breakage is there to tell you that these structures, which have some designed-in relationship, have been broken. It's basically a compile-time assertion on the sizes of those structures. If it were a run-time assertion, then you'd have to guarantee that someone actually tests this code path. By making it compile-time, it brings errors to the developer's attention more quickly. As for whether it has any effect on -g, I don't know. I can't imagine that any competent compiler implementation would have trouble generating proper code for that construct, but I guess I don't have a good imagination for bad compilers ... -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
