(2014/02/04 18:02), Stefan Hajnoczi wrote:> On Tue, Feb 04, 2014 at 02:26:13PM +0900, Kazuya Saito wrote: >> > (2014/01/31 19:37), Stefan Hajnoczi wrote:> On Tue, Jan 28, 2014 at >> > 01:35:20PM +0900, Kazuya Saito wrote: >>>> > >> def h(events): >>>> > >> + pass >>> > > >>> > > I thought all code generation now happens in backends.common.h(), so >>> > > this function will not be called anymore? >> > >> > It is called in tracetool.backend.compatible(). So, it is required when >> > selecting only dtrace backend. >> > >>> > > The same is true for c() defined in this file. >> > >> > It is also required for the same reason as dtrace.h(). > tracetool.backend.compatible() is testing for the existence of a > function that is not used anywhere else. Backend code doesn't make it > obvious why this is necessary. > > We should either make compatible() work (e.g. by testing body_<format> > and ensuring all formats use the "body_" function prefix) or with > something explicit like a <backend>.supported_formats = ['c', 'h'] list.
I think that checking <bakcend>.supported_formats is better. I'll change compatible() like that. >>>> > >> +util-obj-$(CONFIG_TRACE_FTRACE) += multi.o ftrace.o >>> > > >>> > > How about adding multi.o to util-obj-y just like control.o below? All >>> > > these object files are added to libqemuutil.a. The linker will only >>> > > pull in object files that are needed (based on symbol dependencies) so >>> > > there is no harm in uncoditionally building multi.o. >> > >> > If adding multi.o to util-obj-y, compile error occurs when selecting >> > only dtrace backend. This is because the function trace_print_events(), >> > trace_event_set_state_dynamic_backend() and trace_backend_init() are >> > declared doubly in multi.o and default.o. >> > So, I'm going to leave it. Do you have any suggestions? > I guess it should be: > > ifeq ($(CONFIG_TRACE_DEFAULT),y) > util-obj-y += default.o > else > util-obj-y += multi.o > endif Thank you. I'll fix it as above. Thanks, Kazuya Saito
