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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
