How to use gcov?

[Joel Sherrill]

You have better chances of geting everything answered if you 
split topics into multiple messages.  A lot of this has nothing to
do with gcov. :)

Kiran C wrote:
> 
> Hi,
>     I want to use gcov for genrating  code coverage information.I tried
> using the gcov flags along with the psim BSp.But it seems certain functions
> required are not implemnted in the psim libgcc.a .
> So what options do I have?

Remember that running on a simulator is different and in this case has
advantages.  The simulator can itself log trace information with no
modifications to the executable.  So I would take this approach first.

Otherwise (as you note) the PowerPC RTEMS executable has to have a way to 
both capture the information and (guessing) write it to a real file for later
analysis. 

Very likely using gcov and gprof with a simulator are very similar
and also something you might want to ask about on the gcc and crossgcc
lists.

> I tried using the UNIX BSP.( so that I can use gcov)But here also I am
> facing problems.

I missed this on my first shot.  It is possible that gcov requires something
that has been overridden in the synthetic target.  Does gcov work on 
other programs on your machine?  The statements below about understanding
what gcov is doing/invoking is very important.  I suspect the task switching
and changing stacks is confusing it.

> When a declare an array for partition like this
> rtems_unsigned8 Partition[512]  CPU_STRUCTURE_ALIGNMENT;
> I get a warining the it is out of bound of the limits of the object file.
> The CPU_STRUCTURE_ALIGNMENT macro stand for this , __attribute__ ((aligned
> (32)))
> What does this mean?

It means that the request to place the structure on a 32 byte boundary
is not being honored by the object format/linker.

> Later I tried changing the 32 with 16.And incremented the ptr to the array
> base by 4( ie of Partition by 4)
> Then all partition sys calls work.

So it is now aligned on a word boundary not a byte boundary so unsigned32
accesses work again.

> What is actually happening?IS what I have done the right thing to do?

I think so.  It also sounds like CPU_STRUCTURE_ALIGNMENT may be too high
for your tool configuration.  What version of the tools/binutils are
you using?  Was there comparable code to this in the tests that you
copied?  I am wondering what went wrong.

> I am facing problems using Message Queue also.The message queue is
> created,and a message is sent to the use success fuuly.
> But when I call the rtems_message_queue_receive sys call.
> I get the follwing error
> ----------------------------------------
> Stray signal 11
>       0 [sig] tca 665 open_stackdumpfile: Dumping stack trace to
> tca.exe.stackdu
> mp
> Aborted (core dumped)
> -------------------------------------------------

I suspect this is a side-effect call of the gcov.  11 apepars to
be a SIGSEGV which means you have accessed non-existent or
unaligned memory.  Lucky you are debugging this on a simulator
since that makes this easier to catch. :)

My guess is that gcov needs stack information and is not aware
of the RTEMS task stack.  I don't know if open_stackdumpfile
is on the native host or psim so don't know the requirements.

I think things would work better/easier if the simulator itself logged
information  required by gcov to do its analysis.  Asking the
gcov developers what this requires or if someone else has done
work on it would be a good thing at this point.  When adapting
generic infrastructure to embedded environments, you have to
be VERY aware of the unique requirements and carefully take
the differences into account.  You need to be familiar
with what gcov does at run-time on a program to be successful.


> I tried debugging into rtems_message_queue_receive
> =========================================
> gdb) n
> 7      ../../../../../posix/lib/include/rtems/rtems/message.inl: No such
> file or director
> .
>        in ../../../../../posix/lib/include/rtems/rtems/message.inl
> gdb) n
> 5        switch ( location ) {
> gdb) n
> 8            _CORE_message_queue_Seize(
> gdb) n
> 3            if ( _Options_Is_no_wait( option_set ) )
> gdb) n
> 8            _CORE_message_queue_Seize(
> gdb) n
> 3            if ( _Options_Is_no_wait( option_set ) )
> gdb) n
> 8            _CORE_message_queue_Seize(
> gdb) n
> 
> rogram received signal SIGSEGV, Segmentation fault.
> CORE_message_queue_Seize (the_message_queue=0xa20ca9c, id=469827585,
>    buffer=0x60f71c, size=0x4, wait=0, timeout=0)
>    at /rtems-4.5.0/c/src/exec/score/src/coremsgseize.c:81
> 1          *size = the_message->Contents.size;
> ====================================================
> Why is it receiving a Segmentation fault?



Is size aligned?  Is the_message valid?

> Here is my code that I used to test it...
> typedef struct _msg
> {
>  int x;
> }msg;
> msg x,y;
> 
> if
> (rtems_message_queue_create(1,10,sizeof(msg),RTEMS_LOCAL,&id)==RTEMS_SUCCESS
> FUL)
>   printf("MSG Q CREATED\n");
>  if  (rtems_message_queue_send(id,&x,sizeof(msg))==RTEMS_SUCCESSFUL)
>   printf("MSG SENT\n");
>  if
> (rtems_message_queue_receive(id,&y,size,RTEMS_NO_WAIT,0)==RTEMS_SUCCESSFUL)
>  {  printf("MESSAGE RECVDED\n");
>    printf("Y=%d",y.x);
>  }
> ps: This code works fine the psim and pc386 BSP

Which is a strong hint the code is right and there is possibly an alignment
problem that is environment/port/toolset specific. 

> Thanks,
> Kiran

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985