2014-08-16 10:51 GMT+08:00 Chris Johns <chr...@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 <chr...@rtems.org >>>> <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.
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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
