| Summary: | When configured without a specific target 'strip' corrupts the first archive member | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Richard Biener <rguenth> |
| Component: | binutils | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | hjl.tools |
| Priority: | P2 | ||
| Version: | 2.32 | ||
| Target Milestone: | 2.33 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
| Attachments: | test archive with two members in AVR format | ||
Created attachment 12576 [details]
test archive with two members in AVR format
test archive
Fixed in 2.33. *** This bug has been marked as a duplicate of bug 24891 *** Huh, interesting. Did you bisect it to that commit? I would not have thought a memory leak causes this kind of behavior. (In reply to Richard Biener from comment #3) > Huh, interesting. Did you bisect it to that commit? Yes. The patch did a little more than just fix memory leaks. I haven't checked, but it is very likely that the first archive element bfd being left open, or even the element caching, resulted in that bfd being in an inconsistent state after trying a number of format matches then reverting back to the default. |
When you configure binutils for example without support for the avr target then invoking strip on an archive does > strip test.a strip: Unable to recognise the format of the input file `test.a(f7_c_get_s64.o)' note it fails to print the same message for the first archive member which is then corrupted, diff of the ELF header: --- aa 2020-05-29 09:35:53.120535838 +0200 +++ bb 2020-05-29 09:35:48.240467762 +0200 @@ -6,18 +6,18 @@ OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) - Machine: Atmel AVR 8-bit microcontroller + Machine: None Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) - Start of section headers: 568 (bytes into file) the header of the second archive member is OK.