[Bug binutils/28890] memory leak issues in objdump
https://sourceware.org/bugzilla/show_bug.cgi?id=28890 LUO, Changhua changed: What|Removed |Added CC||chluo at link dot cuhk.edu.hk -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28894] segfault when building openjdk13 on x86 32bit (binutils 2.38 regression)
https://sourceware.org/bugzilla/show_bug.cgi?id=28894 --- Comment #16 from Pierre Labastie --- A little late to the party, openjdk-17 builds again too. Thanks for the quick fix. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 --- Comment #14 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6aa1b7df2fc435ba1b744f20db5c6d3013496249 commit 6aa1b7df2fc435ba1b744f20db5c6d3013496249 Author: H.J. Lu Date: Fri Feb 11 15:13:19 2022 -0800 ld: Keep indirect symbol from IR if referenced from shared object Don't change indirect symbol defined in IR to undefined if it is referenced from shared object. bfd/ PR ld/28879 * elflink.c (_bfd_elf_merge_symbol): Don't change indirect symbol defined in IR to undefined if it is referenced from shared object. ld/ PR ld/28879 * testsuite/ld-plugin/lto.exp: Run PR ld/28879 tests. * testsuite/ld-plugin/pr28879a.cc: New file. * testsuite/ld-plugin/pr28879b.cc: Likewise. (cherry picked from commit 20ea3acc727f3be6322dfbd881e506873535231d) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28879] [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors
https://sourceware.org/bugzilla/show_bug.cgi?id=28879 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from H.J. Lu --- Fixed for 2.39 and on 2.38 branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28264] [2.37 Regression] ld.bfd crashes on linking efivar with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=28264 Bug 28264 depends on bug 28879, which changed state. Bug 28879 Summary: [2.38 Regression] ld.bfd: possibly incorrect "undefined reference" errors https://sourceware.org/bugzilla/show_bug.cgi?id=28879 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 Nick Clifton changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #23 from Nick Clifton --- OK, I am reopening this PR. But I am not a Windows expert. So please could somebody suggest a potential patch to fix the problems ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28841] ld: Customize output section type
https://sourceware.org/bugzilla/show_bug.cgi?id=28841 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c212f39d9a82c6c09f4a1447d9d2ff09843827c5 commit c212f39d9a82c6c09f4a1447d9d2ff09843827c5 Author: Fangrui Song Date: Wed Feb 16 17:41:23 2022 + ld: Support customized output section type bfd/ PR ld/28841 * bfd-in2.h (struct bfd_section): Add type. (discarded_section): Add field. * elf.c (elf_fake_sections): Handle bfd_section::type. * section.c (BFD_FAKE_SECTION): Add field. * mri.c (mri_draw_tree): Update function call. ld/ PR ld/28841 * ld.texi: Document new output section type. * ldlex.l: Add new token TYPE. * ldgram.y: Handle TYPE=exp. * ldlang.h: Add type_section to list of section types. * ldlang.c (lang_add_section): Handle type_section. (map_input_to_output_sections): Handle type_section. * testsuite/ld-scripts/output-section-types.t: Add tests. * testsuite/ld-scripts/output-section-types.d: Update. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713
--- Comment #24 from Fred Eisele ---
Here is a sample program that I think demonstrates the relevant functions.
#include
#include
#include
#include
#include
#include
/**
*
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfullpathnamew
*
https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
* @return
*/
int main() {
wchar_t **lpFilePart = {NULL};
const char prefix[] = "?\\";
const char *paths[] = {
"C:\\tools\\foo.o",
"C:\\tools\\.\\foo.o",
"C:\\tools\\msys64\\..\\foo.o",
".\\foo.o",
".\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\test.o",
".\\increasepath\\increasepath\\.\\.\\increasepath\\increasepath\\"
"increasepath\\increasepath\\..\\..\\increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\test.o"
};
setbuf(stderr, NULL);
int loopLimit = sizeof(paths)/sizeof(*paths);
for (int ix = 0; ix < loopLimit; ix++) {
const char *partPathOrig = paths[ix];
/*
* Converting from the partial path from ascii to unicode.
* Calling with lpWideCharStr set to null returns the length.
* Calling with cbMultiByte set to -1 includes the terminating null.
*/
int partPathWSize = MultiByteToWideChar(CP_UTF8, 0, partPathOrig, -1, NULL,
0);
wchar_t *partPath = calloc(partPathWSize, sizeof(wchar_t));
MultiByteToWideChar(CP_UTF8, 0, partPathOrig, -1, partPath, partPathWSize);
fprintf(stderr, "PartPath: size = %d val = %ls\n", partPathWSize,
partPath);
/*
* Getting the full path from the provided partial path.
*
*/
long fullPathWSize = GetFullPathNameW(partPath, 0, NULL, lpFilePart);
wchar_t *fullPath = calloc(fullPathWSize, sizeof(wchar_t));
long copiedPathLen = GetFullPathNameW(partPath, fullPathWSize, fullPath,
lpFilePart);
fprintf(stderr, "PathLen = %d LastError = %d\n", copiedPathLen,
GetLastError());
fprintf(stderr, "FullPath: size = %d val: %ls\n", fullPathWSize, fullPath);
free(fullPath);
free(partPath);
}
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713
--- Comment #25 from Fred Eisele ---
Use of those functions would give us something like...
size_t filelen;
/* PR 25713: Handle extra long path names possibly containing '..' and '.'.
*/
wchar_t **lpFilePart = {NULL};
const char ccs[] = "ccs=UNICODE";
const int partPathLen = strlen(filename);
const char *partPathOrig = calloc(partPathLen, sizeof(char));
/*
* Convert any UNIX style path separators into the DOS form.
*/
for (int ix=0; ix < partPathLen) switch (filename[ix]) {
case '/': partPathOrig[ix] = '\\'; break;
default: partPathOrig[ix] = filename[ix]
}
/*
* Converting from the partial path from ascii to unicode.
* Calling with lpWideCharStr set to null returns the length.
* Calling with cbMultiByte set to -1 includes the terminating null.
*/
int partPathWSize = MultiByteToWideChar(CP_UTF8, 0, partPathOrig, -1, NULL,
0);
wchar_t *partPath = calloc(partPathWSize, sizeof(wchar_t));
MultiByteToWideChar(CP_UTF8, 0, partPathOrig, -1, partPath, partPathWSize);
/*
* Getting the full path from the provided partial path.
* Calling twice: 1) get the length; 2) resolve the path.
*/
long fullPathWSize = GetFullPathNameW(partPath, 0, NULL, lpFilePart);
wchar_t *fullPath = calloc(fullPathWSize, sizeof(wchar_t));
long copiedPathLen = GetFullPathNameW(partPath, fullPathWSize, fullPath,
lpFilePart);
free(partPath);
char* remode = calloc(strlen(modes) + sizeof(ccs) + 1, sizeof(char));
strcpy(remode, modes);
strcat(remode, ccs);
file = fopen (fullPath, remode);
fprintf(stderr, "k26: %d %s\n", errno, strerror(errno));
file = close_on_exec (file);
fprintf(stderr, "k27: %d %s\n", errno, strerror(errno));
free (fullPath);
return file;
--
You are receiving this mail because:
You are on the CC list for the bug.
Re: Checking gold without libc.a
If anyone can confirm that this is not expected behavior, I'm happy to submit a bug report. Is static glibc necessary for "./configure --enable-gold; make; make check" to succeed? Thanks again! On Tue, Feb 15, 2022 at 7:46 AM Mitchell Dorrell wrote: > I have a CentOS system which does not have static glibc libraries > installed (specifically, no libc.a). With binutils 2.38 and the > --enable-gold option, make check fails because gold can't find libc.a. > > Is this expected behavior? Are the static glibc libraries required for > gold's testing suite? > > Without --enable-gold, make check completes successfully. > > Thanks! >
Issue 43372 in oss-fuzz: binutils:fuzz_disas_ext-bfd_arch_i386: Use-of-uninitialized-value in OP_VEX
Updates: Labels: -restrict-view-commit Comment #3 on issue 43372 by sheriffbot: binutils:fuzz_disas_ext-bfd_arch_i386: Use-of-uninitialized-value in OP_VEX https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43372#c3 This bug has been fixed. 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.
Issue 43624 in oss-fuzz: binutils:fuzz_as: Stack-overflow in operand
Updates: Labels: -restrict-view-commit Comment #3 on issue 43624 by sheriffbot: binutils:fuzz_as: Stack-overflow in operand https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43624#c3 This bug has been fixed. 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/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713
--- Comment #26 from Fred Eisele ---
Some tweaks needed to me made to get the _fopen() to work properly.
#include
#include
#include
#include
#include
/* Mark FILE as close-on-exec. Return FILE. FILE may be NULL, in
which case nothing is done. */
static FILE *
close_on_exec(FILE *file) {
#if defined (HAVE_FILENO) && defined (F_GETFD)
if (file)
{
int fd = fileno (file);
int old = fcntl (fd, F_GETFD, 0);
if (old >= 0)
fcntl (fd, F_SETFD, old | FD_CLOEXEC);
}
#endif
return file;
}
/**
*
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getfullpathnamew
*
https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
* @return
*/
int main() {
wchar_t **lpFilePart = {NULL};
const wchar_t prefix[] = L"?\\";
const char *paths[] = {
"C:\\tools\\foo.o",
"C:\\tools\\.\\foo.o",
"C:\\tools\\msys64\\..\\foo.o",
".\\foo.o",
".\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\test.o",
".\\increasepath\\increasepath\\.\\.\\increasepath\\increasepath\\"
"increasepath\\increasepath\\..\\..\\increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\increasepath\\increasepath\\increasepath\\"
"increasepath\\increasepath\\test.o"
};
setbuf(stderr, NULL);
int loopLimit = sizeof(paths) / sizeof(*paths);
for (int ix = 0; ix < loopLimit; ix++) {
const char *filename = paths[ix];
const char modes[] = "w+b";
FILE *file;
fprintf(stderr, "\n");
/* PR 25713: Handle extra long path names possibly containing '..' and '.'.
*/
wchar_t **lpFilePart = {NULL};
const char ccs[] = ", ccs=UNICODE";
const int partPathLen = strlen(filename) + 1;
char *partPathOrig = calloc(partPathLen, sizeof(char));
/*
* Convert any UNIX style path separators into the DOS form.
*/
int ix;
for (ix = 0; ix < partPathLen; ix++)
switch (filename[ix]) {
case '/':
partPathOrig[ix] = '\\';
break;
default:
partPathOrig[ix] = filename[ix];
}
partPathOrig[ix] = 0;
fprintf(stderr, "part: path = %s\n", partPathOrig);
/*
* Converting from the partial path from ascii to unicode.
* Calling with lpWideCharStr set to null returns the length.
* Calling with cbMultiByte set to -1 includes the terminating null.
*/
int partPathWSize = MultiByteToWideChar(CP_UTF8, 0, partPathOrig, -1, NULL,
0);
wchar_t *partPath = calloc(partPathWSize, sizeof(wchar_t));
MultiByteToWideChar(CP_UTF8, 0, partPathOrig, -1, partPath, partPathWSize);
fprintf(stderr, "part: wpath = %ls\n", partPath);
/*
* Getting the full path from the provided partial path.
* Calling twice: 1) get the length; 2) resolve the path.
*/
long fullPathWSize = GetFullPathNameW(partPath, 0, NULL, lpFilePart);
wchar_t *fullPathTmp = calloc(fullPathWSize, sizeof(wchar_t));
long copiedPathLen = GetFullPathNameW(partPath, fullPathWSize, fullPathTmp,
lpFilePart);
fprintf(stderr, "full: errno = %d error = %s\n", errno, strerror(errno));
wchar_t *fullPath = calloc(fullPathWSize + sizeof(prefix),
sizeof(wchar_t));
wcscpy(fullPath, prefix);
wcscat(fullPath, fullPathTmp);
free(partPath);
int remodelSize = strlen(modes) + sizeof(ccs) + 1;
char *remode = calloc(remodelSize, sizeof(char));
strcpy(remode, modes);
strcat(remode, ccs);
wchar_t* remodel = calloc(remodelSize, sizeof(wchar_t));
MultiByteToWideChar(CP_UTF8, 0, remode, -1, remodel, remodelSize);
free(remode);
fprintf(stderr, "file: mode = %ls, fullPath = %ls\n", remodel, fullPath,
remodel);
file = _wfopen(fullPath, remodel);
fprintf(stderr, "file: errno = %d error = %s\n", errno, strerror(errno));
free(remodel);
file = close_on_exec(file);
free(fullPath);
}
return 0;
}
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/28902] New: ld: `not found for insert` error has a weird ordering
https://sourceware.org/bugzilla/show_bug.cgi?id=28902
Bug ID: 28902
Summary: ld: `not found for insert` error has a weird ordering
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
echo 'SECTIONS { .byte : { BYTE(0) } } INSERT AFTER .data;' > insert-data.lds
echo 'SECTIONS { .text : {*(.text)} .data : {*(.data)}}' > a.lds
echo 'SECTIONS { .byte : { BYTE(0) } } INSERT AFTER .note.gnu.build-id;' >
insert-note.lds
echo '.globl _start; _start:; .data; .byte 0' | gcc -c -x assembler - -o a.o
exit
ld.bfd a.o -T insert-data.lds -T a.lds # ok
ld.bfd a.o -T a.lds -T insert-data.lds # .data not found for insert
# Remark: The order is puzzling. If ld processes -T in order, one will expect
that `-T a.lds -T insert-data.lds` works and the other order fails.
ld.bfd a.o -T insert-note.lds --build-id # ok
ld.bfd a.o -T a.lds -T insert-note.lds --build-id # .note.gnu.build-id not
found for insert
ld.bfd a.o -T a.lds -dT insert-note.lds --build-id # ok
# Remark: Why -T fails while -dT works is puzzling. If you specify --verbose,
the used linker script is exactly the same.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/28902] ld: `not found for insert` error has a weird ordering
https://sourceware.org/bugzilla/show_bug.cgi?id=28902
--- Comment #1 from Fangrui Song ---
(I don't have a Fedora machine and I know very little about systemd.)
I was asked why lld doesn't support -dT. I have dug up and found
https://github.com/systemd/package-notes/blob/main/rpm/macros.package-notes-srpm#L52
%_package_note_flags%[%_package_note_status?"-Wl,%["%_package_note_linker"
!= "lld"?"-dT":"-T"],%{_package_note_file}":""]
According to Debian Code Search (
https://codesearch.debian.net/search?q=%5B-%5D%5B-%5Ddefault-script&literal=0&page=1),
no project uses `--default-script` or `Wl,-dT`.
> ld.bfd a.o -T a.lds -dT insert-note.lds --build-id # ok
I suspect this is the reason
https://github.com/systemd/package-notes/blob/main/rpm/macros.package-notes-srpm#L52
uses -dT. But this appears as an ill advice to me, working around a problem
with an obscure option, instead of making the ld maintainer aware of the
problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/28902] ld: `not found for insert` error has a weird ordering
https://sourceware.org/bugzilla/show_bug.cgi?id=28902 Fangrui Song changed: What|Removed |Added CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28902] ld: `not found for insert` error has a weird ordering
https://sourceware.org/bugzilla/show_bug.cgi?id=28902 Zbigniew Jędrzejewski-Szmek changed: What|Removed |Added CC||zbyszek at in dot waw.pl -- You are receiving this mail because: You are on the CC list for the bug.
