MIPS, libsupc++ and -G 0
On MIPS, libgcc is built with -G 0, which is used to ensure the contents don't assume they will be placed in the small data/bss section. Setting -G 0 is used to allow for the possibility of large applications, or those where even small data may be located more than 64k away from the gp pointer. However this is not done with libsupc++ or libstdc++. The result is that for some of my embedded applications, which require -G 0 themselves, "stderr" is far away from the gp pointer. This shouldn't matter except that vterminate.cc in libsupc++ was not compiled with -G 0 and thus is expecting to be able to use a 16-bit gp relative relocation, thus we get a link failure. Was this a conscious decision or an accident? Is the best route for me to just add -G 0 for all mips libstdc++/libsupc++, and submit that as a patch? Thanks in advance, Jifl -- eCosCentrichttp://www.eCosCentric.com/The eCos and RedBoot experts --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
Re: MIPS, libsupc++ and -G 0
Richard Sandiford wrote: Zack Weinberg <[EMAIL PROTECTED]> writes: Richard Sandiford <[EMAIL PROTECTED]> writes: The only reliable way to get what you want is to either (a) add -G0 multilibs or (b) change the default -G setting. Perhaps a configure option would be useful here. Maybe something like --with-sdata-limit, to go alongside options like --with-arch and --with-tune? Or perhaps an -m option to put stuff in .sdata as normal, but generate code as if nothing is in there? Maybe (and I realise other ports do) but in some ways it gives the worst of both worlds. libsupc++ and libstdc++ will end up eating chunks of the small data area without getting any real benefit from it. A configure-time option is likely to be more convenient for folks who use -G0 because you don't have to coerce every build system to add it on the command line. And it wouldn't penalise those who want to use the usual -G8. Unfortunately the decision to use or not use -G 0 isn't taken on a per-compiler basis usually, but a per-application one. A -G 0 multilib doesn't seem good either because someone may have an application that doesn't link with -G 8, but might with -G 4, and at least get some benefit from small data. Or arguably -G 2. I think for what is in effect a system library, Zack's proposal seems least bad, even though it has drawbacks. And potentially no drawbacks if someone ever implements linker relaxation for MIPS. Jifl
Re: rsync access seems to be broken
Volker Reichelt wrote: since two days I cannot synchronize my gcc repository using rsync anymore. Nothing happens and after a some time I get the following error message: Some stale connections were clogging up the rsync port - there's a connection limit of 16. Nearly all of them were from AMD. I expunged the dead connections and it should work better now. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
Re: rsync access seems to be broken
Volker Reichelt wrote: Btw, I get no response for ping gcc.gnu.org Is this intended? Or does this also need fixing? It is intentional. Jifl -- --["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
