Debuggine 4.6.99.3 applications - Resend

[Ian Caddy]

Hi Bob,

I was waiting for someone more knowledgable than me to reply, but looks 
like you have ended up with me.

Some of the information below could well be considered hacks, but 
without getting a valid response to get it working sometimes these 
workarounds are required ... ;-)


Robert S. Grimes wrote:
> 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

Since either 4.6 or 4.7 the debug build of RTEMS seems to be broken, or 
at least not working for us.  That is not really a problem for us, as we 
only use the optimised builds.  It might have been something we did when 
we moved from 4.5 to 4.6 or 4.6 to 4.7, but I have heard other people 
also indicating that it doesn't seem to work for them either.

Remember though as you explained further down in your email that all the 
source (even when optimised) is still build with debug information, the 
code is just optimised.  It can be a bit confusing getting it to step 
through optimised code, but it can be done.

> 
> 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?

The problem above, is that you are building a debug version and it is 
looking for debug libraries, hence the _g.

Now here comes the hack.  You can either change your makefile (we use 
custom makefiles for our applications) to use the libraries without the _g.

Or the easier one is to actually build your optimised code as not 
optimised.  Go into your rtems, in the directory:

make/custom/yourbsp.cfg

where yourbsp is the particular bsp or system you are building.

Change the optimised build CFLAGS to use -O0 instead of -O3

Then rebuild everything, including your application, without the debug 
and you should still be able to debug fine.


> Also, does this make any sense, from an applications developer point of
> view?  

It is just the way the RTEMS make system is put together, this is part 
of the reason we use a custom make environment for our applications.

> Why do I need debug versions of the OS just to debug my own
> code?  

You don't really as long as you don't want to follow too closely what 
goes on in the OS.

> And by the way, everything is built with the -g switch anyways,
> so it really isn't a symbolic issue, right?  

That is correct, we often debug optimised code, as it may be in the 
customer premises and we are trying to track down some elusive problem, 
then we must use the same code as our customers.  It can be a bit of a 
pain but it is possible.

> 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.

This is one of the biggest problems, in tracking optmised code, that and 
inlining, and our optimised stuff is also built without a frame pointer 
so backtracking is very tricky sometimes as well.


> 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?

Since we use a custom make environment for our applications, this is 
pretty much what we do.  You are not really missing anything, although 
it is hard for me to give specific help for your application building, 
since we don't use the same system to build applications.

Our system is a bit different.  We have a Base system that is linked 
with RTEMS, and these things together effectively become the OS for 
other applications which are built separately (but with the same tools) 
and loaded in by the Base application on startup.  The Base application 
provides hooks into RTEMS for all the applications, but none of our 
applications actually get linked with RTEMS.

This is because each unit that we provide is different, with different 
applications, but all containing the Base which includes RTEMS.

I hope this helps.

regards,

Ian Caddy



-- 
Ian Caddy
Goanna Technologies Pty Ltd
+61 8 9221 1860