[Bug binutils/24031] Cannot remove section related to a function (even if the function is in separate section and isn't referenced elsewhere)
https://sourceware.org/bugzilla/show_bug.cgi?id=24031 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- > Andreas, is there a way to remove .text symbols under -ffunction-sections? > This might be in some embedded use-cases. The only way is to link with --gc-sections. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/19962] R_ARM_COPY relocation generated with -znocopyreloc
https://sourceware.org/bugzilla/show_bug.cgi?id=19962 Maxim Kuvyrkov changed: What|Removed |Added CC||maxim.kuvyrkov at gmail dot com --- Comment #2 from Maxim Kuvyrkov --- Hi David, Any feedback on Nick's patch? -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24055] _bfd_xcoff_swap_aux_in smashes the stack
https://sourceware.org/bugzilla/show_bug.cgi?id=24055 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Created attachment 11507 --> https://sourceware.org/bugzilla/attachment.cgi?id=11507&action=edit Proposed patch Hi Wolfgang, I agree that this is a problem, but I do not think that your patch will work. It will fail to copy auxiliary entries for file symbols, if that symbol has more than 1 auxiliary entry. I think that the issue is probably that file symbols should never have more than one or two auxiliary entries, although I could not find an actual specification of that rule. Please could you try out this alternate patch, which does not actually solve the problem, but it should generate an abort rather than allowing the stack to be smashed. (I am hoping that this will allow you to trace the reason for the abort back to a maformed file symbol). If the patch works as I hope, then I would also apply it to the other versions of the swap_aux_in() function that use the same memcpy functionality. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24053] [as] Error: invalid register for .seh_savexmm
https://sourceware.org/bugzilla/show_bug.cgi?id=24053 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=65782 Resolution|--- |INVALID --- Comment #1 from H.J. Lu --- This is a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24055] _bfd_xcoff_swap_aux_in smashes the stack
https://sourceware.org/bugzilla/show_bug.cgi?id=24055 --- Comment #2 from Wolfgang Thaller --- Probably won't work for me; I added an assert myself at first and it did in fact trigger. I am working with an old XCOFF file provided by Apple back in the 90s, and it contains a C_FILE with a total of four aux entries. They are distinguished by their x_ftype field, and contain the source file name, the compile time stamp, the compiler version and some "compiler defined information", respectively. It does not look malformed to me, though of course Apple's 1990s interpretation of XCOFF could have diverged from the one that is still relevant today :-) Also, I am still a bit skeptical. So you are saying that swap_aux_in is supposed to copy all aux entries into one internal_auxent structure? In xcofflink.c:4490, functio xcoff_link_input_bfd, which is where I encountered the stack smashage, swap_aux_in is invoked in a loop over all n_numaux entries. Swap in one aux entry, do something, swap out the one aux entry, advance to next aux entry. The corresponding swap_aux_out function only copies back one at a time; it does not somehow extract multiple aux entries out of a single internal_auxent. In fact, I have not seen any other code that indicates that an iternal_auxent might correspond to more than one external_auxent. The code in xcofflink.c makes perfect sense to me under the assumption that swap_aux_in is supposed to copy only one aux entry, and no sense at all with the present implementation of swap_aux_in. The swap_aux_in function as written also leaves the internal_auxent structure entirely uninitialized if index is not null, which is really scary (and technically UB as well). Also, if the string contents of the AUX entry fit within 14 (E_FILNMLEN) characters, the string is stored inline, otherwise it is stored as a reference to the string table. In the string table case, swap_aux_in only copies the pointers for the current aux entry. The loop that calls it from xcoff_link_input_bfd handles the string table reference after the call. If the first aux entry contains an inline string (<= 14 bytes), then all entries are written into the auxent. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24057] New: objdump memory leaks in xmalloc.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24057
Bug ID: 24057
Summary: objdump memory leaks in xmalloc.c
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: 0x0keeper at gmail dot com
Target Milestone: ---
Created attachment 11508
--> https://sourceware.org/bugzilla/attachment.cgi?id=11508&action=edit
binutil-objdump-memory-leaks-xmalloc
hi,binutils team.i found there is memory leaks in xmalloc.c, when used objdump.
here is AddressSanitizer info.
./binutils/objdump -W poc
.
==24202==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 28672 byte(s) in 4 object(s) allocated from:
#0 0x4b9708 in malloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9708)
#1 0x9b73cf in xrealloc
/root/fuzz/binutils-2.31/libiberty/./xmalloc.c:177:14
#2 0x50ae56 in read_and_display_attr
/root/fuzz/binutils-2.31/binutils/dwarf.c:2696:10
#3 0x50ae56 in process_debug_info
/root/fuzz/binutils-2.31/binutils/dwarf.c:3206
#4 0x5062cb in load_separate_debug_file
/root/fuzz/binutils-2.31/binutils/dwarf.c:9937:11
#5 0x4f2f45 in dump_dwarf
/root/fuzz/binutils-2.31/binutils/./objdump.c:2766:15
#6 0x4ee3be in display_object_bfd
/root/fuzz/binutils-2.31/binutils/./objdump.c:3688:7
#7 0x4ee3be in display_any_bfd
/root/fuzz/binutils-2.31/binutils/./objdump.c:3777
#8 0x4ed553 in display_file
/root/fuzz/binutils-2.31/binutils/./objdump.c:3798:3
#9 0x4ed553 in main /root/fuzz/binutils-2.31/binutils/./objdump.c:4100
#10 0x7fa9ab24b82f in __libc_start_main
/build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
Direct leak of 408 byte(s) in 8 object(s) allocated from:
#0 0x4b9708 in malloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9708)
#1 0x9b723a in xmalloc
/root/fuzz/binutils-2.31/libiberty/./xmalloc.c:147:12
#2 0x4f4a16 in dump_dwarf_section
/root/fuzz/binutils-2.31/binutils/./objdump.c:2694:6
Direct leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x4b9708 in malloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9708)
#1 0x9b723a in xmalloc
/root/fuzz/binutils-2.31/libiberty/./xmalloc.c:147:12
#2 0x5117c8 in display_debug_frames
/root/fuzz/binutils-2.31/binutils/dwarf.c:7497:12
#3 0x4f4a16 in dump_dwarf_section
/root/fuzz/binutils-2.31/binutils/./objdump.c:2694:6
Indirect leak of 204 byte(s) in 4 object(s) allocated from:
#0 0x4b9a88 in realloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9a88)
#1 0x9b73aa in xrealloc
/root/fuzz/binutils-2.31/libiberty/./xmalloc.c:179:14
Indirect leak of 96 byte(s) in 1 object(s) allocated from:
#0 0x4b9708 in malloc (/root/fuzz/binutils-2.31/binutils/objdump+0x4b9708)
#1 0x9b723a in xmalloc
/root/fuzz/binutils-2.31/libiberty/./xmalloc.c:147:12
#2 0x5117c8 in display_debug_frames
/root/fuzz/binutils-2.31/binutils/dwarf.c:7497:12
#3 0x4f4a16 in dump_dwarf_section
/root/fuzz/binutils-2.31/binutils/./objdump.c:2694:6
SUMMARY: AddressSanitizer: 29476 byte(s) leaked in 18 allocation(s).
for example,source code in /binutils-2.31/libiberty/./xmalloc.c:177:14
https://github.com/bminor/binutils-gdb/blob/master/libiberty/xmalloc.c#L177
xrealloc (PTR oldmem, size_t size)
{
PTR newmem;
if (size == 0)
size = 1;
if (!oldmem)
newmem = malloc (size);
else
newmem = realloc (oldmem, size);
if (!newmem)
xmalloc_failed (size);
return (newmem);
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24058] New: objdump memory leaks in readelf.c
https://sourceware.org/bugzilla/show_bug.cgi?id=24058
Bug ID: 24058
Summary: objdump memory leaks in readelf.c
Product: binutils
Version: 2.31
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: 0x0keeper at gmail dot com
Target Milestone: ---
Created attachment 11509
--> https://sourceware.org/bugzilla/attachment.cgi?id=11509&action=edit
binutil-objdump-memory-leaks-readelf
hi,binutils team.i found there is memory leaks in readelf.c, when used objdump.
here is AddressSanitizer info.
./objdump -W poc
==21635==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 54 byte(s) in 2 object(s) allocated from:
#0 0x4b91a8 in __interceptor_malloc
(/root/fuzz/binutils-2.31/binutils/readelf+0x4b91a8)
#1 0x4eb374 in get_data /root/fuzz/binutils-2.31/binutils/readelf.c:425:9
#2 0x5548f0 in get_section_contents
/root/fuzz/binutils-2.31/binutils/readelf.c:13243:20
#3 0x5548f0 in process_notes_at
/root/fuzz/binutils-2.31/binutils/readelf.c:18179
#4 0x5126a9 in process_note_sections
/root/fuzz/binutils-2.31/binutils/readelf.c:18456:10
#5 0x5126a9 in process_notes
/root/fuzz/binutils-2.31/binutils/readelf.c:18492
#6 0x5126a9 in process_object
/root/fuzz/binutils-2.31/binutils/readelf.c:18850
#7 0x4ee043 in process_file
/root/fuzz/binutils-2.31/binutils/readelf.c:19259:13
#8 0x4ee043 in main /root/fuzz/binutils-2.31/binutils/readelf.c:19318
#9 0x7fb198cba82f in __libc_start_main
/build/glibc-Cl5G7W/glibc-2.23/csu/../csu/libc-start.c:291
SUMMARY: AddressSanitizer: 54 byte(s) leaked in 2 allocation(s).
code in binutils-2.31/binutils/readelf.c:425:9
https://github.com/bminor/binutils-gdb/blob/master/binutils/readelf.c#L424
mvar = var;
if (mvar == NULL)
{
/* Check for overflow. */
if (nmemb < (~(bfd_size_type) 0 - 1) / size)
/* + 1 so that we can '\0' terminate invalid string table sections. */
mvar = malloc ((size_t) amt + 1);
if (mvar == NULL)
{
if (reason)
error (_("Out of memory allocating %s bytes for %s\n"),
bfd_vmatoa ("u", amt), reason);
return NULL;
}
((char *) mvar)[amt] = '\0';
}
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24055] _bfd_xcoff_swap_aux_in smashes the stack
https://sourceware.org/bugzilla/show_bug.cgi?id=24055 --- Comment #3 from Wolfgang Thaller --- Comment on attachment 11507 --> https://sourceware.org/bugzilla/attachment.cgi?id=11507 Proposed patch There are also some minor problems with your proposed patch: * The assert checks < sizeof(AUXENT), but AUXENT is the external auxentm and by definition AUXESZ == sizeof(AUXENT), so it looks like this assert will always fail. * The size for the memcpy is numaux * sizeof(AUXESZ), but AUXESZ is the size, not the structure, so sizeof(AUXESZ) == sizeof(18) == sizeof(int) == 4. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24061] New: powerpc-ibm-aix-ar sets bogus file permissions when extracting
https://sourceware.org/bugzilla/show_bug.cgi?id=24061 Bug ID: 24061 Summary: powerpc-ibm-aix-ar sets bogus file permissions when extracting Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: wolfgang.thaller at gmx dot net Target Milestone: --- Created attachment 11510 --> https://sourceware.org/bugzilla/attachment.cgi?id=11510&action=edit a possible fix that works for me Commit 29866fa186ee3ebda5242221607dba360b2e541e introduced a bug where the file mode field is read from .a files as decimal, even though it is stored as octal. This leads to seemingly random permissions on files extracted from an archive. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21786] Stack-buffer-overflow in {coff,coff64}-rs6000.c
https://sourceware.org/bugzilla/show_bug.cgi?id=21786 --- Comment #9 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=677bd4c69d0eda4f2ae635d793f23c0b1413a9e9 commit 677bd4c69d0eda4f2ae635d793f23c0b1413a9e9 Author: Alan Modra Date: Fri Jan 4 12:18:36 2019 +1030 PR24061, powerpc-ibm-aix-ar sets bogus file permissions when extracting Mode field should be read in octal, all the rest in decimal. Do so. PR 24061 PR 21786 * coff-rs6000.c (GET_VALUE_IN_FIELD): Add base parameter and adjust all callers. (EQ_VALUE_IN_FIELD): Likewise. * coff64-rs6000.c (GET_VALUE_IN_FIELD): Likewise. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24061] powerpc-ibm-aix-ar sets bogus file permissions when extracting
https://sourceware.org/bugzilla/show_bug.cgi?id=24061 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=677bd4c69d0eda4f2ae635d793f23c0b1413a9e9 commit 677bd4c69d0eda4f2ae635d793f23c0b1413a9e9 Author: Alan Modra Date: Fri Jan 4 12:18:36 2019 +1030 PR24061, powerpc-ibm-aix-ar sets bogus file permissions when extracting Mode field should be read in octal, all the rest in decimal. Do so. PR 24061 PR 21786 * coff-rs6000.c (GET_VALUE_IN_FIELD): Add base parameter and adjust all callers. (EQ_VALUE_IN_FIELD): Likewise. * coff64-rs6000.c (GET_VALUE_IN_FIELD): Likewise. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/24061] powerpc-ibm-aix-ar sets bogus file permissions when extracting
https://sourceware.org/bugzilla/show_bug.cgi?id=24061 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at sourceware dot org |amodra at gmail dot com --- Comment #2 from Alan Modra --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
