Summary: | Allow profiling option | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | John Richard Moser <nigelenki> |
Component: | [OLD] Development | Assignee: | Please assign to toolchain <gcc-porting> |
Status: | RESOLVED UPSTREAM | ||
Severity: | enhancement | CC: | magnade, sekretarz |
Priority: | Low | ||
Version: | 1.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
John Richard Moser
2003-11-04 11:38:08 UTC
Right, so how far are you with a patch ? Serious now, I do not have time for a big project like this, so feel free, or if anybody else feels up to it ... On the portage end, this looks more like a project for portage-ng, if that plig-in capability works out well. This "profiling" feature could simply be a C/Python plugin. I think this bug needs to be saved for review at a later date once something functional on the portage-ng project gets outputted. I can't rewrite GCC to handle it, unfortunately. If I had the time and skill I would have before sending this in. I see it's been assigned to the GCC porting team and left open for review though, so at least that's something. Maybe someone will in the future. As it is now, the .da files would overlap and flood out the /usr/bin directory and become altogether useless. The biggers issue in my opinion will be the gcc side. Just getting portage to see if there is a foo file, and setting some variable or cp'ing something somewhere is not that a major issue. Definitely. Everything hinges on patching the profiling code to spit out per-binary .da files. Without this, there is no way to make this work due to the inevitable <source file>.da filename overlap. What else would be nice would be to be able to combine multiple profiles and decide what would in general be the best for a library or executable, and then spit out a small file explaining the block ordering, which portage could download with the builds to use for non-profiling builds (GCC by default uses a random model, so sampled models would of course be better in some or most cases). Still, it would rely on sampled user feedback. i think it would be alot quicker and easier if portage was changed to allow profiling to happen easier i did some playing with gcc 3.4 and its profiling a while back all thats really needed is first run, portage told via some command line option, to add -fprofile-generate to cflags then after installing the program keep the source directorys around and change perms so any user can write to the directorys to generate the profiling info, keeping the source files around isnt nessary just the directory structure of the source, then user does some profiling of the apps then remerges the program with another command line option to emerge which adds -fprofile-use to cflags this time then it rebuilds the program using the generated profile data and on this run it can delete the source left over if you wanted to take this farther you would make it so portage would keep the profiling info around between -r versions of the ebuilds original gcc enhancment idea is beyond the Gentoo project if gcc gets said enhancment, we can review again how best to incorporate it into portage |