[PATCH] RTL: Fix options handle and add a new option to rtems-ld
van.freenix at gmail.com
Mon Sep 8 14:32:59 UTC 2014
2014-09-08 14:16 GMT+08:00 Chris Johns <chrisj at rtems.org>:
> On 18/08/2014 12:17 am, Peng Fan wrote:
>> 2014-08-16 10:51 GMT+08:00 Chris Johns <chrisj at rtems.org
>> <mailto:chrisj at 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
>> 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
>> 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,
>> 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'.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel