> 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

Reply via email to