> This is not a sensible path to go IMO. It involves a bunch of work that's > close > to pointless as we will still need DWARF->CTF for gcc. (Unlike getting 'ld' to > do the work, which is a *much* more interesting approach for various reasons.)
And the reasons are? There have been hallway conversations before on how ld(1) might be a more "friendly" focal point for CTF activities - might this not get rid of the post-processing activities a user must *know* how to do? There might also be a precedent in that we already do some stab processing. BUT, this processing is carried out in a self contained support library, that ld(1) passes section information to: % LD_OPTIONS=-Dsupport cc -o main main.c debug: debug: support object request=libldstab.so.1 (default) debug: support object=libldstab.so.1: provides routine ld_start debug: support object=libldstab.so.1: provides routine ld_atexit debug: support object=libldstab.so.1: provides routine ld_file debug: support object=libldstab.so.1: provides routine ld_section The compilers can provide any number of different support libraries. Effectively, the stabs processing is hidden in the support library, ld(1) hasn't a clue what's going on. So, if someone wants to write the appropriate support library, I'm sure we can help "plug it in" :-) -- Rod. This message posted from opensolaris.org _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org