Is sdcc + gputils + gpsim useful ?

I think most experienced C programmers will agree that at least once in
a while a good debugger is needed to find that one, last, elusive bug in
your code ;-)

Since I'm starting to investigate sdcc as a development tool for 16 bit
PICs I'm keen to see how well gpsim works with code produced with sdcc.

The problem I've found is to do with the display of the source
(assembly) code for the code being debugged.

It seems that for gpsim to be able to display this correctly, the source
code needs to be present in the .lst file produced by gplink and
the .asm file needs to be in the current directory when running gpsim.

In the case of code that has come from sdcc "C" libraries neither of
these conditions is satisfied and a blank tab is displayed in the source
browser.

For example, to get the c startup code (crt0i) to be displayed, you can
copy crt0i.asm from the sdcc build tree and put it in the directory with
your own c files, then when sdcc is run and gplink creates the .lst file
both conditions are satisfied and the code from crt0i.asm will be
displayed in the source browser window, and break points etc can be set
in the startup code.

The question is, is it worth trying to come up with a scheme to make
this happen automatically ? 

It will need changes made to sdcc to
1) put the .asm files for libraries somewhere well known so gplink and
gpsim can find them (e.g.   /usr/local/share/sdcc/lib/src/pic16)
2) Add switches to gplink to point at these .asm files.

Changes to gplink will be needed to accept a path definition to use when
looking for .asm files when producing the .lst file.  Maybe this path
information can be included in the .cod file ?

Changes to gpsim to either accept a path for .asm files or to read it
from the .cod file.

Is this worth the effort ?

Peter