On 23/05/11 08:58 AM, James Carlson wrote:
Brian Utterback wrote:
On 05/20/11 22:10, James Carlson wrote:
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 ...
A lot of compilers will turn off all optimizations when -g is used.
Others will turn off some opts. It was not that long ago that you were
not allowed to use -O and -g at the same time. Clearly using the -g
option in this case turns off the compile time optimizations that remove
the bogus function call. This makes sense because the point of -g is to
force the compiler to retain as much as possible the correspondence
between the source code and the generated assembly code so the developer
can debug it in a sane manner.
Disabling optimizations that might confuse those attempting to debug the
code is one thing, but I think leaving in a call that the compiler knows
can't possibly be made (due to constant evaluation) is quite another.
For one thing, the external linkage means that it can trigger dynamic
library loading that (for the "optimized" code) would just never happen.
And I think allowing that would add to (not lessen) the potential
confusion.
I would not expect "-g" to turn off basic constant folding on most
compilers, and this doesn't look like an exception to me.
Well I can tell you that SUNWspro fails to compile
dladm with -g as the command line option.
But, anyway, the point was to explain the construct. It's not an
uncommon way to verify a relationship between structures at compile time.
Another example would be:
if (offsetof(struct mystruct, my_exposed_member) != 16)
someone_broke_binary_compatibility_for_mystruct();
If you know that your compiler (such as gcc) doesn't mind
things like this, use:
#ifdef __GNUC__
if (offsetof(struct mystruct, my_exposed_member) != 16)
someone_broke_binary_compatibility_for_mystruct();
#endif
The behaviour you're expecting is quite rightly compiler
dependent and there's no reason to expect it to work on
every compiler.
I'd actively discourage people from ever writing such code.
Darren
/ws/onnv-tools/SUNWspro/sunstudio12.1/bin/cc -g -m32
-Wc,-Qassembler-ounrefsym=0 -xspace -W0,-Lt -Xa -xildoff -errtags=yes
-errwarn=%all -erroff=E_EMPTY_TRANSLATION_UNIT
-erroff=E_STATEMENT_NOT_REACHED -xc99=%none -Wd,-xsafe=unboundsym
-W2,-xwrap_int -W0,-xglobalstatic -features=conststrings
-DTEXT_DOMAIN="SUNW_OST_OSCMD" -D_TS_ERRNO
-I/net/mintslice.us.oracle.com/biscuit/on-hg_ob2/proto/root_sparc/usr/include
-zguidance -zfatal-warnings -Bdirect
-M/net/mintslice.us.oracle.com/biscuit/on-hg_ob2/usr/src/common/mapfiles/common/map.noexstk
-M/net/mintslice.us.oracle.com/biscuit/on-hg_ob2/usr/src/common/mapfiles/common/map.pagealign
-Wl,-I/lib/ld.so.1 -o dladm dladm.c
-L/net/mintslice.us.oracle.com/biscuit/on-hg_ob2/proto/root_sparc_stub/lib
-L/net/mintslice.us.oracle.com/biscuit/on-hg_ob2/proto/root_sparc_stub/usr/lib
-lsocket -ldladm -ldlpi -lkstat -lbsm -linetutil -ldevinfo -zlazyload
-lrstp -znolazyload
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
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
