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

[Peng Fan]

2014-08-16 10:51 GMT+08:00 Chris Johns <chrisj at rtems.org>:

> On 15/08/2014 7:37 pm, Peng Fan wrote:
>
>>
>> On 08/15/2014 04:15 PM, Chris Johns wrote:
>>
>>> On 14/08/2014 11:21 am, Peng Fan wrote:
>>>
>>>> Hi,
>>>>
>>>> I have a two days travel, so this reply is late.
>>>>
>>>> 2014-08-12 10:56 GMT+08:00 Chris Johns <chrisj at rtems.org
>>>> <mailto:chrisj at rtems.org>>:
>>>>
>>>>     On 11/08/2014 12:24 am, Peng Fan wrote:
>>>>
>>>>
>>>>         1. Fix getopt_long usage in rtl host. some shorthand options
>>>> are not
>>>>         hanlded correctly, this patch fixes it.
>>>>
>>>>
>>>>     Thanks for cleaning this up.
>>>>
>>>>
>>>>         2. Add a new option '--mach-flags'/'-m' to rtems-ld. This optarg
>>>>         of this
>>>>         option will be passed to xx-rtemsxx-gcc, it will be used the
>>>>         search lib
>>>>         dirs. Detailed msg is in the commit log of the patch.
>>>>
>>>>
>>>>     I wonder if we need the explicit -march and -mcpu options and this
>>>>     or should we remove them and add a more general option that can
>>>>     include these flags. When I added the -march etc I thought this was
>>>>     all that was needed and that is proving to be a little naive.
>>>>
>>>> If -march and -mcpu are only passed to gcc to let gcc search the libs, I
>>>> think we can add a more generic option.
>>>>
>>>>
>>>>     What do you think ?
>>>>
>>>>
>>>> I think we can extract the 'machine' related flags from rtems bsp and
>>>> build a table in rtl-host like the following:
>>>> struct bsp_flag {
>>>> char* bsp_name;
>>>> char* flags;
>>>> } ;
>>>> Here machine related flags in gcc is at
>>>> https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/ chapter 3.17.
>>>> struct bsp_flag bsp_flags[RTEMS_BSP_NUMS];
>>>> alloc space
>>>> bsp_flags[0].bsp_name = bsp name from rtems source code
>>>> bsp_flags[0].flags = machine flags from rtems source code corresponding
>>>> to the bsp
>>>> bsp_flags[1]
>>>> bsp_flags[2]
>>>> ......
>>>>
>>>
>>> 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.:)

>
>
>  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?
 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:)

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.

Regards,
Peng.

>
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140817/dd80a685/attachment-0001.html>