This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for "no_instrument_function" attribute

Will Cohen <> writes:

> Andreas Jaeger wrote:
>> Will Cohen <> writes:
>> > Andreas Jaeger wrote:
>> >>
>> >> Will Cohen <> 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
>> section "Bootstrapping and testing"
>> this is not enough.  You need to do a full bootstrap and regression
>> testing,
> 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. :-(

 Andreas Jaeger
  SuSE Labs

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]