On Sun, Jan 13, 2008 at 11:54:16PM +0100, Roland Mainz wrote: > Mike Shapiro wrote: > > On Sat, Jan 12, 2008 at 07:41:30AM +0100, Roland Mainz wrote: > > > Is it "legal" to disable CTF for OS/Net libraries ? I'm asking since CTF > > > has caused nothing but pain for us in the last year, including the > > > C99/VLA issue (which requires some work to "backport" code to use > > > |alloca()| (which is not possible in all cases, e.g. it's not possible > > > to replace a VLA with |alloca()| within a loop)), that the current CTF > > > generation seems to be completely incompatible to the Sun Studio > > > interprocedural optimizer (as consequence performace gets damaged) etc. > > > ... and at some point I'm wondering whether these "costs" are justified > > > by the "benefits" ... > > > > Can you be a bit more specific? I haven't heard of these issues before. > > Uhm... and I thought I was close from being banned from this list > because I'm howling&&wailing too often about it... ;-/ > > > What is the c99/vla issue? > > "VLA" means "variable length arrays" which means you can use an integer
I know what a VLA is. I just need the details of your problem. > -- snip -- > This works Ok with gcc, Sun Studio 10 Studio 11 etc. outside OS/Net but > "ctfconvert" fail because it hit an unknown stab: > -- snip -- > ERROR: ctfconvert: pics/bltins/read.o: Couldn't parse stab > "#vla0:(0,14)" (source file pics/bltins/read.o) > Removing pics/bltins/read.o > -- snip -- > > See http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6575435 > ('ctf tools cannot handle C99 VLAs ("variable length arrays")') ... I'm not sure if you're tried DWARF output instead of stabs, but in any case, yes, given the c99 changes, we should make the ctf tools handle that. Unfortunately team CTF (me and John Levon, if there is such a designation) are both busy on other things at the moment. So if you can't get around with by using the DWARF mode, then feel free to pitch in by proposing a set of diffs and we'll sponsor you: this should be relatively trivial to fix. > > How is ctf incompatible with the interprocedural optimizer? (this > > statement is confusing to me since we're just post-processing debug > > information after the compiler runs). > > Erm... yes... but the XIPO stuff runs the optimizer over all source > files (e.g. doing inlining across source file borders etc.) in one > single step at the _final_ link stage - which seems to shift some stuff > around which the CTF tools don't expect (as I said above I know almost > nothing about CTF... right now I'm only guessing what may be wrong...). By definition, the worst that could do is make the CTF tables of global symbol types incorrect, since they are cross-indexed to the symbol table. But it can't make your program not run or load, and it can't make anything worse happen than the debugging queries be wrong. I suppose it could also make ctfmerge itself fail -- is that what you're seeing? In any case, this could be the result of any post-linking binary modification tool. We can't be responsible for such things in the abstract: the ctf tools provide critical debugging information to os developers. If you're doing a project that requires post-processing optimization for some tangible benefit, then either decide that's more important than CTF, or we need to decide to go fix either the optimizer or ctfmerge to play nice together. At present in Solaris, we don't use such things as part of the tool chain for libraries so it hasn't been an issue. -Mike -- Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/ _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
