On 18/08/2014 12:17 am, Peng Fan wrote:
2014-08-16 10:51 GMT+08:00 Chris Johns <chr...@rtems.org
<mailto:chr...@rtems.org>>:
On 15/08/2014 7:37 pm, Peng Fan wrote:
On 08/15/2014 04:15 PM, Chris Johns wrote:>
I think the user should manage this in their build
environment. The
rtems-tld (trace linker) will need the BSP set up to work so
this is a
different case.
I have not read related source code. what is it for?
The rtems-tld is a trace linker. It is still being worked on and not
usable. Trace linking lets a user define a set of functions they
want to trace and rtems-tld will generate the wrapping functions,
compile them and perform a link using the GNU ld's '--wrap=symbol'
option. This will combine with the capture engine to allow real-time
tracing on targets.
The first pass of the rtems-tld will provide a proof of concept way
to output to stdout entry to a function with the arguments and the
return value shown as hex dumps. The capture engine integration is
happening slowly with Jennifer and is the end objective.
If things work out with rtems-tld the wrapping generators will be
specified in INI files which lets users provide custom ways to trace
execution. The INI files in the repo show the idea being worked on.
I tried rtems-tld and read about the verbose output msg from rtems-tld.
Currently I found that it can only generate wrap functions. rtems-tld is
to generate wrapping functions, compile the generated files with
wrapping functions in it and other source files passed to rtems-tld
using parameters, and link them using '--wrap-symbol'? is the final
linked file is a rap file or others?
is there a protocal between the capture engine and the wrapping
functions? using serial to communicate? I just wonder this.:)
The protocol is defined in configuration files. I have the trace linker
building applications with wrapped function and I now need to add the
code to generate the logging code based on the configuration to show it
is working. My plan is let users play with this stuff in the examples-v2.
Using the machine flags, xxx_rtemsxx_gcc can search the
related libs
first, if not found, then search the common libs,
because the machine
related lib path is in the first.
Yes it can.
Just my thought, the code above is not good. Hmm. using
String, new and
class in c++
I understand.
I think we may pass a madantory bsp name to rtl-host,
such as "--bsp
xxxxxxx" , xxxxxxx means the bsp name
Or we pass --cc-flags and let the user manage the interface
to the BSP.
If not pass correct machine flags to gcc, rtems-ld may link wrong
libgcc.a and other libxxx.a, and rtems-ld can not give any error msg
about this. At last, when loading rap file, error occurs, but
hard to
find what happens.
I am not sure, but I think let user to handle the machine flags
is not
user friendly, unless users are clearly about what machine flags
should
be passed to xx-rtemsxx-gcc by rtems-ld.
If using --cc-flags, this option may be manatory, but not
optional. And
the user should extract the machine flags from rtems source code.
I think passing bsp name to rtems-ld, and rtems-ld search a
table which
contains bsps' name and the machine flags corresponding to the
bsp. If
the bsp name passed to rtems-ld can not be found in the table,
rtems-ld
complains err msg, If found, then all is fine.
This sounds reasonable. Maybe we provide both and users can decide.
The bsp option may be suitable and may need some extra options or
they can provide the full list and not specify a bsp.
1. using a bsp option. extra options?
I have added support for the arch/bsp and/or cflags with a default (path
based) or user supplied compiler or linker (absolute paths).
2. they can provide the full list. You mean let user define the
machine flags? like "--machine-flags "-mthumb -msoft-float -mxxx" "?
Anyway, I do not have enough experience. You decide. To me, I'd like to
use a bsp option, and as u said users can also decide. I am newbie:)
This is supported via the cflags options.
Which ever way we go the rtems-ld and rtems-tld should be the similar.
If the final image generated by rtems-tld is not a dynamically loadable
elf/rap file, i think it is not needed to make rtems-tld have the same
saying '--bsp' option with rtems-ld. Because the machine flags passed to
xx-rtemsxx-gcc only affects the rap/elf dynamically loadable file.
The rtems-tld currently has a little bit more code to set the compiler
and linker. This is useful if you want to use absolute paths to the
compiler and linker rather than depend on paths.
I have made a number of changes and I have not tested rtems-ld. Are you
able to run some tests on rtems-ld for me ?
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
