Hide Forgot
2. What is the nature and description of the request? The customer has observed that 'ld' can sometimes cause the system to spend a large amount of time and resources (to the point of preventing any interactivity with the system) while generating the Build ID. This happens in particular on systems with a large amount of memory when compiling programs with a large (but not larger than available memory) .bss section. This request is to add logic to ld to check for this scenario and either avoid it or print a warning. 3. Why does the customer need this? (List the business requirements here) There is no specific business impact to the customer; he knows how to avoid the problem that this solves. However, he feels it would be of potential benefit to other users to have this functionality implemented. 4. How would the customer like to achieve this? (List the functional requirements here) This only applies when --build-id is not explicitly set. ld would attempt to detect when generating the sha1sum for the Build ID would take a long time and be very resource-intensive. It would then either: 4a. Abort the linking and require passing an explicit option to continue (either setting --build-id explicitly or passing an option such as --force-build-id) 4b. Leave the .bss section out of the Build ID computation. This has the advantage of being easier to detect in code - we could simply hard-code a threshold size for the .bss section, and if it exceeds this size, do not include in it the sha1sum input. 4c. Continue normally, but print a warning that the compilation may cause hangs/performance issues/take a long time. Include information about overriding with --build-id in this warning. 5. For each functional requirement listed in question 4, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. A test program that creates an arbitrarily-sized bss section is already attached to the ticket. We could use this program to confirm that the behavior is triggered under the right circumstances. Additionally, the customer could verify that his machine no longer experiences hangs when compiling without the --build-id option. 6. Is there already an existing RFE upstream or in Red Hat bugzilla? No. 7. How quickly does this need resolved? (desired target release) No specific release is desired; this is simply something the customer considers a good idea, and he has an indefinite workaround (--build-id=none) 8. Does this request meet the RHEL Inclusion criteria (please review) Yes, for either a major or a minor release. 9. List the affected packages binutils 10. Would the customer be able to assist in testing this functionality if implemented? Yes
Created attachment 491541 [details] Sample program that demonstrates the problem Here is a simple test case that shows the problem. To demonstrate the issue, set MEM to something larger than the total avail memory of the system (so that a malloc() call of that size will fail), and compile with: gcc gcc_test.c -o gcc_test -lm -lc -Dx86_64 -fPIC -m64 -O Then, set MEM to something smaller than avail memory (so that malloc will succeed), but still very large, and compile again. On RHEL 6, the second compile should take a very long time, and gcc can be observed to be consuming an amount of memory equal to MEM GB.
It was conditionally nakd some time ago due to engineering capacity. I can't see any way it's going to make 6.3. I'll go ahead and turn the cond_nak into a full nak and put it on the 6.4 queue.
Marking as duplicate of 809616, which is a public bug. 809616 is scheduled to be resolved for RHEL 6.3. *** This bug has been marked as a duplicate of bug 809616 ***