Hi Chris,
2014-09-08 14:16 GMT+08:00 Chris Johns <chr...@rtems.org>: > 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 ? I tried rtems-ld to compile python.rap for arm realview_pbx_qemu_a9 bsp using such options: '-B arm/realview_pbx_qemu_a9 -r /opt/rtems-4.11' and rtems-ld can link the final rap image. At last when load the python.rap, the simpile xx.py file can be correctly executed. Yeah, I do some debug, and found that use '-B' can let gcc search the correct libs. I found that '-B' and '-r' should be set both, otherwise rtems-ld will complains errors 'No RTEMS path provide with arch/bsp'. Regards, Peng. > > > Chris >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
