Mail Archives: djgpp/2000/04/19/02:17:52
On Tue, 18 Apr 2000, Steamer wrote:
> Unfortunately, regparm is incompatible with profiling (at least in
> GCC 2.8.1, which I'm using) because the -pg option inserts code
> at the beginning of each function which trashes eax and edx (and
> maybe ecx, which I didn't look at) and therefore destroys the passed
> parameters - with inevitably gruesome results.
I suggest to report this to the GCC maintainers. The GCC docs does
not mention this incompatibility, so it's either a documentation bug,
or a GCC bug, if it is supposed to work.
I suspect the former. In general, GCC maintainers will tell you that
if you use switches that change the ABI, you should expect certain
things to break. For example, there are some switches of this kind
that break debugging.
> Has this been fixed in later versions?
I don't have any idea. Anybody?
> Of course, it's possible to work around it with something like
>
> #if defined __DJGPP__ && !defined PROFILING
> #define REGPARM(n) __attribute__ ((regparm(n)))
> #else
> #define REGPARM(n)
> #endif
>
> but then it's necessary to remember -DPROFILING in addition to -pg.
If you are willing to live without regparm when profiling and profile
code that doesn't use regparm, then why is this an issue? You could
simply compile only some functions with -pg and leave those which use
regparm without profiling instrumentation. Since regparm will
ususally be limited to a well-defined small subset of your program, it
shouldn't be too hard to decide how to compile each module.
I thought the issue was that you *wanted* to profile code _while_ it
was using regparm (for obvious reasons).
- Raw text -