Issue 19261 in oss-fuzz: binutils:fuzz_disassemble: Timeout in fuzz_disassemble
Updates: Labels: -restrict-view-commit Comment #4 on issue 19261 by sheriff...@chromium.org: binutils:fuzz_disassemble: Timeout in fuzz_disassemble https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19261#c4 This bug has been fixed for 30 days. It has been opened to the public. - 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.
[Bug ld/25374] New: linking to msvc import library results in invalid IDT entry
https://sourceware.org/bugzilla/show_bug.cgi?id=25374 Bug ID: 25374 Summary: linking to msvc import library results in invalid IDT entry Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: draymond at foxvalley dot net Target Milestone: --- I have a DLL that I built and linked with i686-w64-mingw32-gcc. It imports functions from two other images (an MSVC-built EXE and DLL). I linked against the import libraries of the MSVC images (foo.lib and bar.lib) using '-lfoo -lbar' on the command line. No errors were reported. When I loaded the MinGW DLL and called into it I experienced a crash. The MinGW DLL was able to call functions in the MSVC DLL but when it tried to call a function in the MSVC EXE the import library thunk pulled an invalid address from the IAT (import address table). It appears that the loader did not fill in the IAT. Examination of the .idata section in the MinGW DLL revealed that ILT and IAT tables were present for both the MSVC DLL and EXE. The IDT entry (which contains pointers to the ILT and IAT) was correct for the MSVC DLL. The IDT entry for the MSVC EXE, however, was incorrect. The ILT and IAT pointers pointed to the NULL entries at the end of the tables rather than the first entries. For this reason 'objdump -p mingw.dll' shows the import table for the MSVC EXE as empty. This also explains why the loader did not fill in the IAT. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25374] linking to msvc import library results in invalid IDT entry
https://sourceware.org/bugzilla/show_bug.cgi?id=25374 Martin Storsjö changed: What|Removed |Added CC||martin at martin dot st --- Comment #1 from Martin Storsjö --- (In reply to Dan Raymond from comment #0) > Examination of the .idata section in the MinGW DLL revealed that ILT and IAT > tables were present for both the MSVC DLL and EXE. The IDT entry (which > contains pointers to the ILT and IAT) was correct for the MSVC DLL. The IDT > entry for the MSVC EXE, however, was incorrect. The ILT and IAT pointers > pointed to the NULL entries at the end of the tables rather than the first > entries. I was able to reproduce a similar issue when linking against two import libraries for two DLLs (without involving the concept of EXEs exporting symbols and import libraries for them). My suspicion is that the synthesized import table chunks (when using msvc style import libraries, where the linker needs to synthesize the import table contents) aren't sorted correctly if there's more than one msvc style import library involved. -- You are receiving this mail because: You are on the CC list for the bug.
