[Bug libsframe/29856] libsframe asan: load misaligned at sframe.c:516

https://sourceware.org/bugzilla/show_bug.cgi?id=29856 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug ld/29823] ld riscv: undefined elf_backend_obj_attrs_handle_unknown causes segfault when merging .riscv.attributes

https://sourceware.org/bugzilla/show_bug.cgi?id=29823 Alan Modra changed: What|Removed |Added Target||riscv64-*-* -- You are receiving this m

[Bug binutils/29822] objdump no longer prints right mnemonic for prefix 3E

https://sourceware.org/bugzilla/show_bug.cgi?id=29822 Alan Modra changed: What|Removed |Added Target||i386-*-* -- You are receiving this mail

[Bug gas/29666] [2.40 Regression] gas/riscv/insn fails on riscv64-linux-gnu

https://sourceware.org/bugzilla/show_bug.cgi?id=29666 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug ld/29376] multiple definition of weak symbols on MinGW toolchain

https://sourceware.org/bugzilla/show_bug.cgi?id=29376 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug ld/27452] ld: Support compressing arbitrary sections (generalized --compress-debug-sections=)

https://sourceware.org/bugzilla/show_bug.cgi?id=27452 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receivi

[Bug binutils/16523] support xz compression of debug info files

https://sourceware.org/bugzilla/show_bug.cgi?id=16523 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receivi

[Bug binutils/29189] dlltool delaylibs corrupt float/double arguments

https://sourceware.org/bugzilla/show_bug.cgi?id=29189 Alan Modra changed: What|Removed |Added Assignee|unassigned at sourceware dot org |amodra at gmail dot com Ever

[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 Jose E. Marchesi changed: What|Removed |Added Last reconfirmed||2023-05-14 Assignee|unas

[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #7 from Jose E. Marchesi --- While implementing this in GNU poke [1] I noticed that the base64 value encoded in ASCII after the // is mutilated, since in order to fit in six characters it is omitting the trailing two padding charac

[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #6 from Jose E. Marchesi --- The LLVM code assumes big-endian. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #5 from Sven --- This is the PE format specification by Microsoft: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format It does not mention base64. It only mentions the decimal integer encoding with one preceding slash.

[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #4 from Sven --- As I wrote, I did not find any specification. This seems to be related: https://reviews.llvm.org/D118692 LLVM's COFF/Writer.cpp might be a good start. I haven't looked into those, yet. -- You are receiving this

[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #3 from Jose E. Marchesi --- Regardless of the target endianness? Is there a spec for this somewhere? Otherwise, it would be good to look at llvm's PE support and make sure the endianness is always big. -- You are receiving this

[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #2 from Sven --- //AAph7S is an example of a section name from the attached file. The part after the two slashed decodes to the byte sequence 00 0a 61 ed. So i'm pretty sure, the byte order is big endian. -- You are receiving thi

[Bug binutils/30444] Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 Jose E. Marchesi changed: What|Removed |Added CC||jose.marchesi at oracle dot com --

[Bug binutils/30444] New: Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 Bug ID: 30444 Summary: Implementation of COFF/PE format lacks base64 support (Extended COFF Object) Product: binutils Version: 2.38 Status: UNCONFIRMED Sever

[Bug binutils/30376] windres cannot parse rc files which it itself generated

https://sourceware.org/bugzilla/show_bug.cgi?id=30376 --- Comment #7 from Pali Rohár --- I did also another test. I took very simple resource file: $ cat test-resource.rc resource_name1 resource_type1 { "resource_string_data1" } resource_name2 "resource_type2" { "resource_string_data2" } "resour

[Bug binutils/30376] windres cannot parse rc files which it itself generated

https://sourceware.org/bugzilla/show_bug.cgi?id=30376 --- Comment #6 from Pali Rohár --- Hello Nick! Now I tried your patch. Now it is better because windres can compile its own generated rc file. But there are still issues. I did more repeated conversions between binary and text file via these

[Bug ld/30421] Symbols in import lib are influenced by .def file

https://sourceware.org/bugzilla/show_bug.cgi?id=30421 --- Comment #4 from LIU Hao --- >From binutils/MAINTAINERS: ``` The home page for binutils is: http://www.gnu.org/software/binutils/binutils.html and patches should be sent to: binut...@sourceware.org ``` -- You are receiving this