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

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #16 from Sven --- If you have something to review or test, let me know -- 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 #15 from Sven --- (In reply to Sven from comment #2) > //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

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

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #13 from Sven --- (In reply to Jose E. Marchesi from comment #12) > Ok, this is worse than I thought :) > > Given the section name //AAph7S, the corresponding base64 to decode is > 00AAph7S, _not_ AAph7S==. > > Found it the hard

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

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #10 from Sven --- Created attachment 14883 --> https://sourceware.org/bugzilla/attachment.cgi?id=14883&action=edit assembly file generated from test.c with x86_64-w64-mingw32-gcc (In reply to Jose E. Marchesi from comment #9) >

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

https://sourceware.org/bugzilla/show_bug.cgi?id=30444 --- Comment #8 from Sven --- (In reply to Jose E. Marchesi from comment #7) > 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

[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 #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] New: Implementation of COFF/PE format lacks base64 support (Extended COFF Object)

Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: sven.koehler at gmail dot com Target Milestone: --- Created attachment 14879 --> https://sourceware.org/bugzilla/attachment.cgi?id=14879&action=

[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r

https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Sven changed: What|Removed |Added CC||sven.koehler at gmail dot com -- You are

[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0

https://sourceware.org/bugzilla/show_bug.cgi?id=27297 Sven changed: What|Removed |Added CC||sven.koehler at gmail dot com -- You are

[Bug ld/18174] New: Improve documentation on Forced Output Section Alignment

Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: sven.koehler at gmail dot com I'm referring to https://sourceware.org/binutils/docs-2.25/ld/Forced-Output-Alignment.html The documentation given there is insufficient. An Output Se

[Bug ld/18173] New: Output Section LMA Alignment

Assignee: unassigned at sourceware dot org Reporter: sven.koehler at gmail dot com With a linker script, it is currently not possible to specify the alignment of the LMA of an output section. Consider the following example: .data : ALIGN(8) { ... } >RAM AT>ROM That will align the VMA

[Bug ld/15889] Don't remove leading underscore of __stdcall functions in PE export table

https://sourceware.org/bugzilla/show_bug.cgi?id=15889 Sven changed: What|Removed |Added Summary|Follow microsoft convention |Don't remove leading |for na

[Bug ld/15889] Follow microsoft convention for naming of __stdcall function in PE-Export table

http://sourceware.org/bugzilla/show_bug.cgi?id=15889 Sven changed: What|Removed |Added Target||i686-w64-mingw32 Host|

[Bug ld/15889] New: Follow microsoft convention for naming of __stdcall function in PE-Export table

: enhancement Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: sven.koehler at gmail dot com When creating shared libraries (i.e. DLLs) using mingw-w64 or mingw32 toolchains, the names of functions in the PE-Export table of the DLL

[Bug binutils/12634] New: improve objdump's way of showing non-executable sections

http://sourceware.org/bugzilla/show_bug.cgi?id=12634 Summary: improve objdump's way of showing non-executable sections Product: binutils Version: 2.21 Status: NEW Severity: enhancement Priority: P2 Compon