Debuggine 4.6.99.3 applications

[Robert S. Grimes]

Alright, I'm very confused right now.  Looking at it from an application
developer's point of view, what is the correct way to build a "debug"
version of my application?  And what is required to build it?  To
provide a bit of context, I would think the following commands, executed
from the application directory, would make sense:

    $ make debug
    $ insight

And I should be up and running in the debugger.  However, the make
command fails because my installation is missing; errors like the
following are displayed:

    powerpc-rtems-gcc:
    /usr/rtems/4.6.99.3/powerpc-rtems/virtex/lib/no-dpmem_g.rel: No such
    file or directory
    powerpc-rtems-gcc:
    /usr/rtems/4.6.99.3/powerpc-rtems/virtex/lib/no-event_g.rel: No such
    file or directory
    powerpc-rtems-gcc:
    /usr/rtems/4.6.99.3/powerpc-rtems/virtex/lib/no-msg_g.rel: No such
    file or directory
    powerpc-rtems-gcc:
    /usr/rtems/4.6.99.3/powerpc-rtems/virtex/lib/no-mp_g.rel: No such
    file or directory
    powerpc-rtems-gcc:
    /usr/rtems/4.6.99.3/powerpc-rtems/virtex/lib/no-part_g.rel: No such
    file or directory
    powerpc-rtems-gcc:
    /usr/rtems/4.6.99.3/powerpc-rtems/virtex/lib/no-signal_g.rel: No
    such file or directory
    powerpc-rtems-gcc:
    /usr/rtems/4.6.99.3/powerpc-rtems/virtex/lib/no-timer_g.rel: No such
    file or directory
    powerpc-rtems-gcc:
    /usr/rtems/4.6.99.3/powerpc-rtems/virtex/lib/no-rtmon_g.rel: No such
    file or directory

How do I fix this?  I've seen old messages that state a "make debug
debuginstall" type command in the RTEMS build directory works, but I
don't think so anymore.  I tried "make VARIANT=debug", but nothing new
is built.  What is the current practice?

Also, does this make any sense, from an applications developer point of
view?  Why do I need debug versions of the OS just to debug my own
code?  And by the way, everything is built with the -g switch anyways,
so it really isn't a symbolic issue, right?  It really is a question of
disabling optimization so the developer can follow code execution (at
least it is for me!), and not have variables optimized out of existence.

Perhaps I'm not asking the right questions, but it seems to me that I
need the following:

   1. Full release build (meaning fully optimized, for "burning into
      EPROM");
   2. Application debug build (meaning non-optimized, debug-friendly
      application code, but optimized BSP and OS code)
   3. BSP debug build (meaning non-optimized, debug-friendly application
      and BSP code, but optimized OS code)
   4. Full debug build (meaning non-optimized, debug-friendly
      application, BSP, and OS code)

Actually, I probably don't need setup 4, but some people do (of course,
they already know how to set that up, I'm sure!). 
Anyway, what is the correct approach to building these build types?  Am
I missing something here?

Thanks again!
-Bob