Debuggine 4.6.99.3 applications - Resend

[Robert S. Grimes]

Hi Ian,

Thanks for the clarification.  Detailed comments below...

-Bob

Ian Caddy wrote:
> 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 ... ;-)
Understood.
>
>
> 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.
Yeah, I guess that's so: 
http://www.rtems.com/ml/rtems-users/2005/january/msg00267.html
>> 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.
Yes, and this is one fundamental problem, IMHO.  The "make debug"
command, I would think, should create a debug version of the
application, but with optimized OS and BSP (scenario 2 of my original
post).  To clarify something I probably forgot to, I am using the
"default" makefiles; more specifically, I have been working with the
"hello_world_c" and the "netdemo" example programs.  I would expect
that, especially when building provided samples, that "make debug" would
work properly, without having to be expert enough to build and install a
separate build of the OS!  And more to the point, in this scenario, I
_don't_ want the debug (i.e. non-optimized) OS anyway; I'm just trying
to debug my application.
>
> 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.
Again, IMHO, I think that this should be the default behavior of the
(application) makefiles to begin with!
>
> 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.
This seems a little more hack-ish, but also an option, I suppose.
>> 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.
Well, what I meant was, when I use "make debug" for my application...
>
>> 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.
>
I certainly agree - this was a GREAT decision they made!
>> 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.
This is important to me now, as I'm trying to customize a BSP for the
Xilinx Virtex-FX parts.