<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-08-16 10:51 GMT+08:00 Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 15/08/2014 7:37 pm, Peng Fan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 08/15/2014 04:15 PM, Chris Johns wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 14/08/2014 11:21 am, Peng Fan wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I have a two days travel, so this reply is late.<br>
<br>
2014-08-12 10:56 GMT+08:00 Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a><br>
<mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>>:<br>
<br>
On 11/08/2014 12:24 am, Peng Fan wrote:<br>
<br>
<br>
1. Fix getopt_long usage in rtl host. some shorthand options<br>
are not<br>
hanlded correctly, this patch fixes it.<br>
<br>
<br>
Thanks for cleaning this up.<br>
<br>
<br>
2. Add a new option '--mach-flags'/'-m' to rtems-ld. This optarg<br>
of this<br>
option will be passed to xx-rtemsxx-gcc, it will be used the<br>
search lib<br>
dirs. Detailed msg is in the commit log of the patch.<br>
<br>
<br>
I wonder if we need the explicit -march and -mcpu options and this<br>
or should we remove them and add a more general option that can<br>
include these flags. When I added the -march etc I thought this was<br>
all that was needed and that is proving to be a little naive.<br>
<br>
If -march and -mcpu are only passed to gcc to let gcc search the libs, I<br>
think we can add a more generic option.<br>
<br>
<br>
What do you think ?<br>
<br>
<br>
I think we can extract the 'machine' related flags from rtems bsp and<br>
build a table in rtl-host like the following:<br>
struct bsp_flag {<br>
char* bsp_name;<br>
char* flags;<br>
} ;<br>
Here machine related flags in gcc is at<br>
<a href="https://gcc.gnu.org/onlinedocs/gcc-4.8.3/gcc/" target="_blank">https://gcc.gnu.org/<u></u>onlinedocs/gcc-4.8.3/gcc/</a> chapter 3.17.<br>
struct bsp_flag bsp_flags[RTEMS_BSP_NUMS];<br>
alloc space<br>
bsp_flags[0].bsp_name = bsp name from rtems source code<br>
bsp_flags[0].flags = machine flags from rtems source code corresponding<br>
to the bsp<br>
bsp_flags[1]<br>
bsp_flags[2]<br>
......<br>
</blockquote>
<br>
I think the user should manage this in their build environment. The<br>
rtems-tld (trace linker) will need the BSP set up to work so this is a<br>
different case.<br>
<br>
</blockquote>
I have not read related source code. what is it for?<br>
</blockquote>
<br></div></div>
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.<br>
<br>
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.<br>
<br>
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.</blockquote><div>
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?</div>
<div> is there a protocal between the capture engine and the wrapping functions? using serial to communicate? I just wonder this.:)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Using the machine flags, xxx_rtemsxx_gcc can search the related libs<br>
first, if not found, then search the common libs, because the machine<br>
related lib path is in the first.<br>
</blockquote>
<br>
Yes it can.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Just my thought, the code above is not good. Hmm. using String, new and<br>
class in c++<br>
</blockquote>
<br>
I understand.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we may pass a madantory bsp name to rtl-host, such as "--bsp<br>
xxxxxxx" , xxxxxxx means the bsp name<br>
</blockquote>
<br>
Or we pass --cc-flags and let the user manage the interface to the BSP.<br>
</blockquote>
If not pass correct machine flags to gcc, rtems-ld may link wrong<br>
libgcc.a and other libxxx.a, and rtems-ld can not give any error msg<br>
about this. At last, when loading rap file, error occurs, but hard to<br>
find what happens.<br>
I am not sure, but I think let user to handle the machine flags is not<br>
user friendly, unless users are clearly about what machine flags should<br>
be passed to xx-rtemsxx-gcc by rtems-ld.<br>
If using --cc-flags, this option may be manatory, but not optional. And<br>
the user should extract the machine flags from rtems source code.<br>
I think passing bsp name to rtems-ld, and rtems-ld search a table which<br>
contains bsps' name and the machine flags corresponding to the bsp. If<br>
the bsp name passed to rtems-ld can not be found in the table, rtems-ld<br>
complains err msg, If found, then all is fine.<br>
</blockquote>
<br></div>
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.<br>
<br></blockquote><div> 1. using a bsp option. extra options?</div><div> 2. they can provide the full list. You mean let user define the machine flags? like "--machine-flags "-mthumb -msoft-float -mxxx" "?</div>
<div>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:)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Which ever way we go the rtems-ld and rtems-tld should be the similar.</blockquote><div>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. </div>
<div><br></div><div>Regards,</div><div>Peng.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Chris<br>
</font></span></blockquote></div><br></div></div>