From: kaz K. <kk...@rr...> - 2003-05-07 00:03:57
|
Hi, >I feel like every time I upgrade tools I spend a day chasing after >__fpscr_values... > >Kaz, it looks like the current state of the tools has it in (for >Linux) start.S in glibc, which puts it in crt1.o. That means there's >no copy of it in libm; just references to it. But libm is built with >-z defs, so the undefined reference is an error. > >Why did it move out of crti.o? Because it should be an unique object in the execution. FPSCR has the bits to control the behavior for math exceptions and if there are multiple __fpscr_values objects, we can't control this behavior. To avoid -z defs issue, you could use no-z-defs=yes in libc configparms. Yes, it removes all useful checks with -z defs, but... It might be better to add a new ld option to allow an exception for -z defs something like --allow-shlib-undefined-sym SYMBOL. Anyway, sorry for forgetting to write this issue to these list. About __fpscr_values issue itself, Joern Rennecke and Alexandre Oliva said independently to me that one solution is to give a fixed address for __fpscr_values and support it by GCC. Perhaps stack top would be a candidate. Regards, kaz |