[Bug ld/30970] New: [rfe] please include HPA segelf work
https://sourceware.org/bugzilla/show_bug.cgi?id=30970 Bug ID: 30970 Summary: [rfe] please include HPA segelf work Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: stsp at users dot sourceforge.net Target Milestone: --- Hi guys. I've recently discovered this binutils fork by HPA: https://git.syslinux.org/users/hpa/segelf/binutils.git/ Which implements this elf extension proposal: https://git.syslinux.org/users/hpa/segelf/abi.git/tree/segelf.txt I've also found his nasm elf16 fork: https://github.com/netwide-assembler/nasm/tree/elf16 I built these things locally and ported my project to this segelf scheme without a slightest issue: https://github.com/dosemu2/fdpp/issues/172#issuecomment-1760271090 So its an absolutely marvelous piece of code, but unfortunately HPA has lost an interest to it many years ago. How feasible would it be for binutils gurus to take it over and upstream? I myself can't tell if something is missing in his impl. But it works for me perfectly well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30969] New: ar cannot be safely invoked in parallel on windows
https://sourceware.org/bugzilla/show_bug.cgi?id=30969 Bug ID: 30969 Summary: ar cannot be safely invoked in parallel on windows Product: binutils Version: 2.42 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sterpumihai at gmail dot com Target Milestone: --- Created attachment 15167 --> https://sourceware.org/bugzilla/attachment.cgi?id=15167=edit patch for adding getpid() to temp file name It seems there is a race condition in ar which is closely related to the usage of mkstemp in function make_tempname (bucomm.c). In certain situations, due to the implementation of mkstemp, the same "unique" file name is generated. This results in a sporadic error of ar: "ar.exe: could not create temporary file whilst writing archive: Permission denied" I repoduced this on Windows on a test system where ar was invoked in parallel. My investigation revealed that all ar invocations used the same temporary file name, "stP1kAlM". This is because the implementation of mkstemp provided by gnulib always uses seed value 0. They do use clock() but given ar calls mkstemp pretty quick, the resolution of clock() on Windows (millisecond) yields the same result. There are basically two solutions here: 1. Investigate and fix the race condition (might prove difficult) OR 2. Add some process specific information to the temporary file name. I personally used getpid() and appended it between "st" and "XX" so each ar invocation truly has a different temporary file. See attached patch. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 60774 in oss-fuzz: binutils:fuzz_dwarf: Out-of-memory in fuzz_dwarf
Updates: Labels: Deadline-Approaching Comment #2 on issue 60774 by sheriffbot: binutils:fuzz_dwarf: Out-of-memory in fuzz_dwarf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=60774#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
