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

[Chris Johns]

On 9/09/2014 12:32 am, Peng Fan wrote:


2014-09-08 14:16 GMT+08:00 Chris Johns mailto:chr...@rtems.org>>:

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


I have just updated the code so the -r is only needed if rtems-ld is not 
installed. If installed giving it a valid prefix it will set the RTEMS 
path (-r) to the prefix. This means if you build RTEMS and install it 
and built the rtl-host code and installed it the paths will default to 
the $prefix.


The test to determine the prefix is ok and not great but should work for 
standard installs. Anything else requires the -r option.


Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [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 :

> On 18/08/2014 12:17 am, Peng Fan wrote:
>
>>
>> 2014-08-16 10:51 GMT+08:00 Chris Johns > >:
>> 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
>> xxx" , xxx 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

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

[Chris Johns]

On 18/08/2014 12:17 am, Peng Fan wrote:


2014-08-16 10:51 GMT+08:00 Chris Johns 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
xxx" , xxx 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 i

Re: [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 :

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

 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
 xxx" , xxx 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. Th

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

[Chris Johns]

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 mailto:chr...@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.



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
xxx" , xxx 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.


Which ever way we go the rtems-ld and rtems-tld should be the similar.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [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 mailto:chr...@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
xxx" , xxx 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


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Chris Johns]

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 mailto:chr...@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.



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
xxx" , xxx means the bsp name


Or we pass --cc-flags and let the user manage the interface to the BSP.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Peng Fan]

Hi,

I have a two days travel, so this reply is late.

2014-08-12 10:56 GMT+08:00 Chris Johns :

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

Just my thought, the code above is not good. Hmm. using String, new and
class in c++

I think we may pass a madantory bsp name to rtl-host, such as "--bsp
xxx" , xxx means the bsp name

Regards,
Peng.

>
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Chris Johns]

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.


What do you think ?

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Peng Fan]

Hi,

1. Fix getopt_long usage in rtl host. some shorthand options are not
hanlded correctly, this patch fixes it.
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.

Regards,
Peng.


0001-Fix-getopt_long-usage.patch
Description: Binary data


0001-Add-a-new-option-to-handle-gcc-machine-flags.patch
Description: Binary data
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel