Error in Trace-buffering example

[Chris Johns]

On 19/03/2018 18:41, Vidushi Vashishth wrote:
>>> The -B option should have a full path not a partial one. The $prefix used when
>>> building the BSP is missing.
>>>
>> >Did you use a full path? Is there an argument missing to the invocation?
>>>
> 
> Adding full path to the -B option works. Turns out $prefix is not required in
> the command. 
> 

Excellent.

>>The link provided to our wiki does not have the full path. I am not sure why ...
> 
> The wiki description also does not show the full path for fileio.exe and init.o.
> I made changes to the command to overcome the errors. Should I raise a ticket to
> make the changes?

Please update the wiki and explain the role the path and $prefix has.

> 
> However now on trying to run the trace link command (which follows) I am
> encountering an error:
> 
> Command:
> 
> rtems-tld -C fileio-trace.ini -W fileio-wrapper --
> -B/Users/vidushi/development/rtems/5/sparc-rtems5/erc32/lib/ -specs bsp_specs
> -qrtems -mcpu=cypress -O2 -g -ffunction-sections -fdata-sections -Wall
> -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes
> -Wnested-externs -Wl,--gc-sections -mcpu=cypress -o
> sparc-rtems5/c/erc32/testsuites/samples/fileio/fileio.exe
> sparc-rtems5/c/erc32/testsuites/samples/fileio/init.o
> 
> 
> Error:
> 
> error: /Users/vidushi/development/rtems/kernel/erc32: Invalid RTEMS path>
> 
> According to the wiki documentation the rtems-path in the configuration file
> should be set to the installed BSP. 

Yes.

> 
> 
> Following is the [fileio-options] section of my configuration file:
> 
> 
> ;--------------------------------------------------------------------------
> 
> [fileio-options]
> 
> dump-on-error = true
> 
> ;
> 
> ; Tools
> 
> ;
> 
> prefix = /Users/vidushi/development/rtems/5
> 
> rtems-path = /Users/vidushi/development/rtems/kernel/erc32
> 
> rtems-bsp = sparc/erc32
> 
> ;
> 
> ; Generator options.
> 
> ;
> 
> gen-enables = enable
> 
> gen-triggers = enable
> 
> 
> ;--------------------------------------------------------------------------
> 
> 
> My rtems-path does point to the installed BSP directory. I can't think of a
> reason for this error.
> 

Interesting, I wonder if the changes that have been made with files has broken
the test? The check is here ...

https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-rtems.cpp#n52

It takes the path you give it, ie 'path ()', and adds 'lib' and 'pkgconfig' and
does the check:

 /Users/vidushi/development/rtems/kernel/erc32/lib/pkgconfig

Is this path present?

> On an unrelated note I am working on my proposal and would try to submit it by
> end of today. For the past couple of days I have been trying to make the
> trace-buffering example work and am hoping to solve the #2780 ticket. I have
> also been going through the work of previous GSOC interns in the same project
> trying to ascertain if I can carry forward from where they left off. Hence I
> wanted to ask if trying to implement the live-tracing functionality over several
> transport mechanisms would be a viable goal for the proposal? Assuming it wasn't
> finished.

Over TCP at this point in time would be best. I suggest you have a look at the
libdebugger's implementation on how to implement a remote interface that can be
changed with other transports:

https://git.rtems.org/rtems/tree/cpukit/include/rtems/debugger/rtems-debugger-remote.h
https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-remote-tcp.h
https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-remote-tcp.c

> 
> Also, given the paucity of time would you suggest that I finish the proposal
> first or my patch for the aforementioned ticket.  
> 

Please get your submission sorted out and then the ticket after that.

Chris