Mike Shapiro wrote:
> On Sun, Jan 13, 2008 at 11:54:16PM +0100, Roland Mainz wrote:
> > Mike Shapiro wrote:
[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,
Erm... no... it seems I completely overlooked this option...
<...some-quick-testing...>
It seems that setting DEBUGFORMAT=-xdebugformat=dwarf in our Makefiles
solves the VLA problem... :-) :-) :-)
... which triggers three questions:
1. Why isn't -xdebugformat=dwarf the default for OS/Net ?
2. Is there any "catch" if I add DEBUGFORMAT=-xdebugformat=dwarf to our
Makefiles ?
3. Who can approve the usage of DEBUGFORMAT=-xdebugformat=dwarf in
OS/Net Makefiles ? Gatekeepers ?
> 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.
AFAIK Richard Lowe had a hack which modified ctfconvert to ignore this
error... but as I said I'm not sure whether this kind of "hacks" are
welcome/correct/etc. or not...
> > > 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?
"ctfmerge" itself fails with:
-- snip --
ERROR: ctfmerge: Input file pics/common/cdt/dtclose.o was partially
built from C sources, but no CTF data was present
Removing libast.so.1
-- snip --
> In any case, this could be the result of any post-linking binary modification
> tool.
Which AFAIK includes stuff like -xipo and -xbinopt... ;-/
> We can't be responsible for such things in the abstract: the ctf tools
> provide critical debugging information to os developers.
Right... actually my original email was a bit of "playing the devils
advocate" to figure out if the pain caused by "CTF bites { VLA, XIPO ...
}" has a limit or not... ;-/
> 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.
(Dumb ?!) question: Is it possible to run the CTF tools only once for
the final executable or will the linker pass remove information which is
required for the CTF tools to function ?
> 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.
Right... but maybe this changes in the future (at least VLA could
replace many cases where currently the code uses |alloca()| while most
canidates for "-xipo" live in SFW (which AFAIK doesn't use CTF right
now...)) ...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
