Mark, > Thanks for taking the time to submit these bugs. I've joined the forum > and will keep my eyes open for assembler issues (I help maintain it).
great. I happen to test GCC on both SPARC and x86 regularly (and have commit access to the GCC SVN repository), so I'm interested in keeping it in good shape on Solaris as far as my time and abilities allow. Until recently, I've mainly followed the easy path (i.e. use Sun as on SPARC, GNU as on x86, and Sun ld on both), but recently (to provide a baseline for one of my patches) was forced to try some less common combinations, where (as expected) several bugs lurked. I try to report all of them to the appropriate maintainers and fix/work around as much as I can. > I looked into this particular bug and have a potential fix. The > assembler emitted a sh_info=1 with the following rationale: there are no > local symbols, therefore the last local symbol index is undefined, index > 0 is designated as the undefined symbol index, therefore one greater > than 0 is 1, therefore sh_info=1. This, coupled with a symbol table This seems right: gab41.pdf, p.61 (Figure 4-12) seems to support if not require this. > size=0, doesn't seem to pose a problem for the Solaris linker but does > for gld. Modifying the assembler to emit sh_info=0 in this instance > appears to work for both linkers (and still comply with the Sparc ABI. > See http://www.sparc.com/standards/gabi31.pdf ). Great. > > If I understand things correctly, the codebase for /opt/SUNWspro/bin/fbe > > and /usr/ccs/bin/as is the same, and fixes to the first will eventually > > make it to the second (which is regularly used by GCC, at least on SPARC; > > the x86 as is largely unusable for GCC). > > Yes, that is correct. Fine. Two questions here: * Are there plans to open at least the assembler codebase? This might help to faster get to the root of problems. * In the past, it used to be possible to build GCC on x86 with the Sun as at least for the 32-bit case. When I recently tried this, I failed miserably. This may well be a GCC bug (I'll check) or a workaround might be possible. For the 64-bit case, it was never possible to use anything but GNU as, although I filed some bug reports early during the CodeSourcery port to Solaris 10/x64. Would it be worthwhile to file bugs to get this fixed? Recent Sun Studio Express release notes seem to indicate that fbe has been updated to be more gas compatible lately. Alternatively, one could declare defeat and just use gas with GCC. Regards. Rainer ----------------------------------------------------------------------------- Rainer Orth, Faculty of Technology, Bielefeld University
