This is the mail archive of the
mailing list for the GCC project.
Re: Patch for "no_instrument_function" attribute
Will Cohen <firstname.lastname@example.org> writes:
> Andreas Jaeger wrote:
>> Will Cohen <email@example.com> writes:
>> > Andreas Jaeger wrote:
>> >> Will Cohen <firstname.lastname@example.org> writes:
>> >> > The attribute "no_instrument_function" allows the support routines for
>> >> > "-finstrument-functions" to be compiled with the same set of options
>> >> > as other functions. The operation of this attribute has been extended
>> >> > to apply to "-p" and "-pg" options. This will make it much easier to
>> >> > compile multilibs such as newlib and have the profiling support within
>> >> > the
>> >> > library. The profiling support functions should be compiled without
>> >> > profiling. With this extension to the "no_instrument_function"
>> >> > attribute the profiling support routines in the library will be
>> >> > compiled correctly regardless of whether a profiling option is passed
>> >> > to the compiler. Is it okay to apply this patch?
>> >> Did you test it? Please tell us how and where.
>> > Yes, I did test it. The patched FSF gcc compiler bootstraps without
>> > problem. This was on an RH 7.2 machine generating a native
>> > i686-pc-linux-gnu compiler. I performed a "make compare"; that didn't
>> > turn up any problems. I also verified that the change disables the
>> According to the build instructions on
>> http://gcc.gnu.org/contribute.html section "Bootstrapping and testing"
>> this is not enough. You need to do a full bootstrap and regression
> Here are the test results. I have compared them with an unaltered
> verison of gcc compiled on the same machine. The weren't any
> regressions due to the change.
Thanks - that information was all I wanted to hear.
>> Good. Do you have a test case for this?
> I just eyeballed the results; I didn't write the test as a complete
> dejagnu test. I haven't addressed the issues to make this an automated
> test. This would be just a compile test, but not all target supports
> profiling. The test isn't tied to a particular architecture, but rather
> the support of profiling. The test also need to look at the output of
> compiler to determine whether the generation of profiling calls has been
> suppressed. I have attached the test program, no_inst.c, to this mail. I
> am open to suggestions on how to adapt this code, so that this attribute
> feature is automatically tested.
I fear for such tests we need to run the object file through objdump.
Currently no such framework exists in GCC and therefore we can't
really do such testing. :-(
SuSE Labs email@example.com