[PATCH] RTL: Fix options handle and add a new option to rtems-ld

[Peng Fan]

Hi Chris,


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
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140908/ece17509/attachment.html>