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

[Peng Fan]

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?
>> 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.

Regards,
Peng.
>
> Chris