[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 Mark Johnston changed: What|Removed |Added CC|am...@freebsd.org | -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #15 from Mark Johnston --- (In reply to Ed Maste from comment #14) Yeah, the original problem is still not fixed on head. I tried with a gcc9-compiled amd64 kernel. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #14 from Ed Maste --- (In reply to Mark Johnston from comment #13) Ok, we still have work to do then. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #13 from Mark Johnston --- (In reply to Ed Maste from comment #12) Not sure. I'll try to repro the issue on head at least. With an llvm-compiled kernel readelf still uses quite a lot of memory (something like 2GB) and emits a bunch of these errors: readelf: dwarf_formudata failed: Invalid attribute form [dwarf_formudata(245)] -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #12 from Ed Maste --- Mark do you know if your original issue is fully covered by the now-MFC'd changes? -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #11 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sat Nov 7 23:58:00 UTC 2020 New revision: 367466 URL: https://svnweb.freebsd.org/changeset/base/367466 Log: Sync up elftoolchain with head, except for the capsicum-related commits, which are incompatible with stable/11. MFC r308465 (by emaste): c++filt: flush output after newline Some tools spawn c++filt and pass it a single line at a time for demangling. This is akin to r276689 for addr2line. Sponsored by: The FreeBSD Foundation MFC r317626 (by emaste): revert r308465: c++filt: flush output after newline The ELF Tool Chain update to r3520 uses setvbuf to set line buffering. Sponsored by: The FreeBSD Foundation MFC r340746 (by oshogbo): strings: fix style nits Reviewed by: cem, emaste, Joseph Koshy Differential Revision:https://reviews.freebsd.org/D18036 MFC r340750 (by mjg): strings: unbreak the build after r340746 Discussed with: oshogbo Sponsored by: The FreeBSD Foundation MFC r342918 (by emaste): Update to ELF Tool Chain r3668 Highlights: - Make sure that only TLS sections are sorted into TLS segment. - Fixed multiple errors in "Section to Segment mapping". - Man page updates - ar improvements - elfcopy: avoid filter_reloc uninitialized variable for rela - elfcopy: avoid stripping relocations from static binaries - readelf: avoid printing directory in front of absolute path - readelf: add NT_FREEBSD_FEATURE_CTL FreeBSD note type - test improvements NOTES: Some of these changes originated in FreeBSD and simply reduce diffs between contrib and vendor. ELF Tool Chain ar is not (currently) used in FreeBSD, and there are improvements in both FreeBSD and ELF Tool Chain ar that are not in the other. Sponsored by: The FreeBSD Foundation MFC r343592 (by emaste): readelf: decode flag bits in DT_FLAGS/DT_FLAGS_1 Decode d_val when the tag is DT_FLAGS or DT_FLAGS_1 based on the information at: https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-42444.html PR: 232983 Submitted by: Bora Ozarslan borako.ozars...@gmail.com Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D18784 MFC r343593 (by emaste): readelf: fix i386 build Use %jx and (uintmax_t) cast. PR: 232983 Sponsored by: The FreeBSD Foundation MFC r343614 (by emaste): readelf: dump elf note data Output format is compatible with GNU readelf's handling of unknown note types (modulo a GNU char signedness bug); future changes will add type- specific decoding. Reviewed by: kib Relnotes: Yes Sponsored by: The FreeBSD Foundation MFC r343665 (by emaste): readelf: use table-based DT_FLAGS and DT_FLAGS_1 decoding Fewer lines of code and more maintainable. Reviewed by: brooks, kib Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D19053 MFC r343669 (by emaste): readelf: decode FreeBSD note types Decode NT_FREEBSD_ABI_TAG, NT_FREEBSD_ARCH_TAG, and NT_FREEBSD_FEATURE_CTL. Reviewed by: brooks, kib (earlier) Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D19054 MFC r345360 (by oshogbo): strings: do not depend on stdin Instead of depending on one stdin FILE structure and use freopen(3), pass to the functions appropriate FILE structure. Reviewed by: cem Discussed with: emaste Differential Revision:https://reviews.freebsd.org/D18037 MFC r345361 (by oshogbo): strings: do not continue if getc or getcharacter returns EOF Reported by: cem MFC r345362 (by oshogbo): Fix powerpc and arm builds after r345361. Reported by: jenkins MFC r345364 (by oshogbo): In case of ENCODING_8BIT the EOF code will be pass to putchar. EOF check should be done before (uint8_t)c > 127 test. Reported by: cem MFC r345431 (by oshogbo): strings: return an error code and the char value separately If we returning 32 bits value it's hard to distinguish if the returned value is a valid one or if its an error (in case of EOF). For that reason separate exit code of the function from the returned character. Reported by: cem, se MFC r345593 (by markj): Prepend DW_AT_comp_dir to relative line number directory table entries. Relative directories may appear in the line number program for a CPU if files were included via a relative path, for instance with "-I.". Previously, dwarf_srclines(3) and dwarf_srcfiles(3) would return the relative path, so addr2line, for instance, would do the same. However, we can get an absolute path by prepending the compilation directory, so change libdwarf to do that to improve compatibility with GNU binutils and since it is more useful in
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #10 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sat Nov 7 23:58:00 UTC 2020 New revision: 367466 URL: https://svnweb.freebsd.org/changeset/base/367466 Log: Sync up elftoolchain with head, except for the capsicum-related commits, which are incompatible with stable/11. MFC r308465 (by emaste): c++filt: flush output after newline Some tools spawn c++filt and pass it a single line at a time for demangling. This is akin to r276689 for addr2line. Sponsored by: The FreeBSD Foundation MFC r317626 (by emaste): revert r308465: c++filt: flush output after newline The ELF Tool Chain update to r3520 uses setvbuf to set line buffering. Sponsored by: The FreeBSD Foundation MFC r340746 (by oshogbo): strings: fix style nits Reviewed by: cem, emaste, Joseph Koshy Differential Revision:https://reviews.freebsd.org/D18036 MFC r340750 (by mjg): strings: unbreak the build after r340746 Discussed with: oshogbo Sponsored by: The FreeBSD Foundation MFC r342918 (by emaste): Update to ELF Tool Chain r3668 Highlights: - Make sure that only TLS sections are sorted into TLS segment. - Fixed multiple errors in "Section to Segment mapping". - Man page updates - ar improvements - elfcopy: avoid filter_reloc uninitialized variable for rela - elfcopy: avoid stripping relocations from static binaries - readelf: avoid printing directory in front of absolute path - readelf: add NT_FREEBSD_FEATURE_CTL FreeBSD note type - test improvements NOTES: Some of these changes originated in FreeBSD and simply reduce diffs between contrib and vendor. ELF Tool Chain ar is not (currently) used in FreeBSD, and there are improvements in both FreeBSD and ELF Tool Chain ar that are not in the other. Sponsored by: The FreeBSD Foundation MFC r343592 (by emaste): readelf: decode flag bits in DT_FLAGS/DT_FLAGS_1 Decode d_val when the tag is DT_FLAGS or DT_FLAGS_1 based on the information at: https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-42444.html PR: 232983 Submitted by: Bora Ozarslan borako.ozars...@gmail.com Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D18784 MFC r343593 (by emaste): readelf: fix i386 build Use %jx and (uintmax_t) cast. PR: 232983 Sponsored by: The FreeBSD Foundation MFC r343614 (by emaste): readelf: dump elf note data Output format is compatible with GNU readelf's handling of unknown note types (modulo a GNU char signedness bug); future changes will add type- specific decoding. Reviewed by: kib Relnotes: Yes Sponsored by: The FreeBSD Foundation MFC r343665 (by emaste): readelf: use table-based DT_FLAGS and DT_FLAGS_1 decoding Fewer lines of code and more maintainable. Reviewed by: brooks, kib Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D19053 MFC r343669 (by emaste): readelf: decode FreeBSD note types Decode NT_FREEBSD_ABI_TAG, NT_FREEBSD_ARCH_TAG, and NT_FREEBSD_FEATURE_CTL. Reviewed by: brooks, kib (earlier) Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D19054 MFC r345360 (by oshogbo): strings: do not depend on stdin Instead of depending on one stdin FILE structure and use freopen(3), pass to the functions appropriate FILE structure. Reviewed by: cem Discussed with: emaste Differential Revision:https://reviews.freebsd.org/D18037 MFC r345361 (by oshogbo): strings: do not continue if getc or getcharacter returns EOF Reported by: cem MFC r345362 (by oshogbo): Fix powerpc and arm builds after r345361. Reported by: jenkins MFC r345364 (by oshogbo): In case of ENCODING_8BIT the EOF code will be pass to putchar. EOF check should be done before (uint8_t)c > 127 test. Reported by: cem MFC r345431 (by oshogbo): strings: return an error code and the char value separately If we returning 32 bits value it's hard to distinguish if the returned value is a valid one or if its an error (in case of EOF). For that reason separate exit code of the function from the returned character. Reported by: cem, se MFC r345593 (by markj): Prepend DW_AT_comp_dir to relative line number directory table entries. Relative directories may appear in the line number program for a CPU if files were included via a relative path, for instance with "-I.". Previously, dwarf_srclines(3) and dwarf_srcfiles(3) would return the relative path, so addr2line, for instance, would do the same. However, we can get an absolute path by prepending the compilation directory, so change libdwarf to do that to improve compatibility with GNU binutils and since it is more useful in
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #9 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sat Nov 7 19:55:07 UTC 2020 New revision: 367462 URL: https://svnweb.freebsd.org/changeset/base/367462 Log: Sync up elftoolchain with head, except for the capsicum-related commits, which are incompatible with stable/12. MFC r345360 (by oshogbo): strings: do not depend on stdin Instead of depending on one stdin FILE structure and use freopen(3), pass to the functions appropriate FILE structure. Reviewed by: cem Discussed with: emaste Differential Revision:https://reviews.freebsd.org/D18037 MFC r345361 (by oshogbo): strings: do not continue if getc or getcharacter returns EOF Reported by: cem MFC r345362 (by oshogbo): Fix powerpc and arm builds after r345361. Reported by: jenkins MFC r345364 (by oshogbo): In case of ENCODING_8BIT the EOF code will be pass to putchar. EOF check should be done before (uint8_t)c > 127 test. Reported by: cem MFC r345431 (by oshogbo): strings: return an error code and the char value separately If we returning 32 bits value it's hard to distinguish if the returned value is a valid one or if its an error (in case of EOF). For that reason separate exit code of the function from the returned character. Reported by: cem, se MFC r346323 (by emaste): readelf: speed up readelf -wo Use an array instead of STAILQ, and sort at the end instead of while adding new elements. PR: 212539 Submitted by: Bora ?zarslan Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC r346327 (by emaste): readelf: use size_t for object counts PR: 212539 Reported by: cem Sponsored by: The FreeBSD Foundation MFC r348776 (by csjp): Teach readelf about some OpenBSD ELF program headers - Add constants for OpenBSD wxneeded, bootdata and randomize to the FreeBSD elf_common.h file. This is the file that gets used by the elftoolchain library. - Update readelf and elfdump utilities to decode these program headers if they are encountered. Note: FreeBSD has it's own version of elfdump(1), which will be updated in a subsequent commit. I am adding it here anyway because this diff is going to be submitted upstream. Discussed with: emaste Reviewed by: imp MFC afer: 2 weeks Differential Revision:https://reviews.freebsd.org/D20548 Mcontrib/elftoolchain/elfdump/elfdump.c Mcontrib/elftoolchain/readelf/readelf.c Msys/sys/elf_common.h MFC r349510 (by luporl): [PowerPC64] readelf: print description for 'e_flags' in ELF header (ABI type) This prints out description text with the meaning of 'Flags' value in PowerPC64. Example: $ readelf -h ~/tmp/t1-Flag2 ELF Header: Magic: 7f 45 4c 46 02 02 01 09 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, big endian Version: 1 (current) OS/ABI:FreeBSD ABI Version: 0 Type: EXEC (Executable file) Machine: PowerPC 64-bit Version: 0x1 Entry point address: 0x1001 Start of program headers: 64 (bytes into file) Start of section headers: 209368 (bytes into file) Flags: 0x2, OpenPOWER ELF V2 ABI Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 10 Size of section headers: 64 (bytes) Number of section headers: 34 Section header string table index: 31 Submitted by: alfredo.junior_eldorado.org.br Reviewed by: luporl Differential Revision:https://reviews.freebsd.org/D20782 MFC r350511 (by emaste): readelf: decode NT_GNU_PROPERTY_TYPE_0 / GNU_PROPERTY_X86_FEATURE_1_AND These bits are used for Intel CET IBT/Shadow Stack. Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D20516 MFC r354544 (by emaste): elfcopy/strip: Ensure sections have required alignment on output Object files may specify insufficient alignment on certain sections, for example due to a bug in NASM[1]. When we detect that case in elfcopy or strip, emit a warning and increase the alignment to the minimum required. The NASM bug was fixed in 2015[2], but we might as well have this fixup (and warning) in elfcopy in case we encounter such a file for any other reason. This might be reworked somewhat upstream - see ELF Tool Chain ticket 485[3]. [1] https://bugzilla.nasm.us/show_bug.cgi?id=3392307 [2] https://repo.or.cz/w/nasm.git/commit/1f0cb0f2c1ba632c0fab02424928cfb756a9160c [3] https://sourceforge.net/p/elftoolchain/tickets/485/
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #8 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sat Nov 7 19:55:07 UTC 2020 New revision: 367462 URL: https://svnweb.freebsd.org/changeset/base/367462 Log: Sync up elftoolchain with head, except for the capsicum-related commits, which are incompatible with stable/12. MFC r345360 (by oshogbo): strings: do not depend on stdin Instead of depending on one stdin FILE structure and use freopen(3), pass to the functions appropriate FILE structure. Reviewed by: cem Discussed with: emaste Differential Revision:https://reviews.freebsd.org/D18037 MFC r345361 (by oshogbo): strings: do not continue if getc or getcharacter returns EOF Reported by: cem MFC r345362 (by oshogbo): Fix powerpc and arm builds after r345361. Reported by: jenkins MFC r345364 (by oshogbo): In case of ENCODING_8BIT the EOF code will be pass to putchar. EOF check should be done before (uint8_t)c > 127 test. Reported by: cem MFC r345431 (by oshogbo): strings: return an error code and the char value separately If we returning 32 bits value it's hard to distinguish if the returned value is a valid one or if its an error (in case of EOF). For that reason separate exit code of the function from the returned character. Reported by: cem, se MFC r346323 (by emaste): readelf: speed up readelf -wo Use an array instead of STAILQ, and sort at the end instead of while adding new elements. PR: 212539 Submitted by: Bora ?zarslan Reviewed by: markj Sponsored by: The FreeBSD Foundation MFC r346327 (by emaste): readelf: use size_t for object counts PR: 212539 Reported by: cem Sponsored by: The FreeBSD Foundation MFC r348776 (by csjp): Teach readelf about some OpenBSD ELF program headers - Add constants for OpenBSD wxneeded, bootdata and randomize to the FreeBSD elf_common.h file. This is the file that gets used by the elftoolchain library. - Update readelf and elfdump utilities to decode these program headers if they are encountered. Note: FreeBSD has it's own version of elfdump(1), which will be updated in a subsequent commit. I am adding it here anyway because this diff is going to be submitted upstream. Discussed with: emaste Reviewed by: imp MFC afer: 2 weeks Differential Revision:https://reviews.freebsd.org/D20548 Mcontrib/elftoolchain/elfdump/elfdump.c Mcontrib/elftoolchain/readelf/readelf.c Msys/sys/elf_common.h MFC r349510 (by luporl): [PowerPC64] readelf: print description for 'e_flags' in ELF header (ABI type) This prints out description text with the meaning of 'Flags' value in PowerPC64. Example: $ readelf -h ~/tmp/t1-Flag2 ELF Header: Magic: 7f 45 4c 46 02 02 01 09 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, big endian Version: 1 (current) OS/ABI:FreeBSD ABI Version: 0 Type: EXEC (Executable file) Machine: PowerPC 64-bit Version: 0x1 Entry point address: 0x1001 Start of program headers: 64 (bytes into file) Start of section headers: 209368 (bytes into file) Flags: 0x2, OpenPOWER ELF V2 ABI Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 10 Size of section headers: 64 (bytes) Number of section headers: 34 Section header string table index: 31 Submitted by: alfredo.junior_eldorado.org.br Reviewed by: luporl Differential Revision:https://reviews.freebsd.org/D20782 MFC r350511 (by emaste): readelf: decode NT_GNU_PROPERTY_TYPE_0 / GNU_PROPERTY_X86_FEATURE_1_AND These bits are used for Intel CET IBT/Shadow Stack. Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D20516 MFC r354544 (by emaste): elfcopy/strip: Ensure sections have required alignment on output Object files may specify insufficient alignment on certain sections, for example due to a bug in NASM[1]. When we detect that case in elfcopy or strip, emit a warning and increase the alignment to the minimum required. The NASM bug was fixed in 2015[2], but we might as well have this fixup (and warning) in elfcopy in case we encounter such a file for any other reason. This might be reworked somewhat upstream - see ELF Tool Chain ticket 485[3]. [1] https://bugzilla.nasm.us/show_bug.cgi?id=3392307 [2] https://repo.or.cz/w/nasm.git/commit/1f0cb0f2c1ba632c0fab02424928cfb756a9160c [3] https://sourceforge.net/p/elftoolchain/tickets/485/
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #7 from Mark Johnston --- Was this ever MFCed? -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 Ed Maste changed: What|Removed |Added Status|New |In Progress -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #6 from commit-h...@freebsd.org --- A commit references this bug: Author: emaste Date: Wed Apr 17 17:50:44 UTC 2019 New revision: 346327 URL: https://svnweb.freebsd.org/changeset/base/346327 Log: readelf: use size_t for object counts PR: 212539 Reported by: cem Sponsored by: The FreeBSD Foundation Changes: head/contrib/elftoolchain/readelf/readelf.c -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #5 from Ed Maste --- (In reply to Conrad Meyer from comment #4) Even if no reasonable application is going to have that many elements, size_t is the proper type for this. Will update. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #4 from Conrad Meyer --- (In reply to commit-hook from comment #3) > Author: emaste > Date: Wed Apr 17 17:00:16 UTC 2019 > New revision: 346323 > URL: https://svnweb.freebsd.org/changeset/base/346323 Would it makes sense to bump the size of la_list_cap and la_list_len to size_t? 4 billion is a lot of items, but sometimes we encounter it in other areas. I don't know much about this particular tool so please excuse this comment if it is completely inappropriate. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 Conrad Meyer changed: What|Removed |Added Assignee|b...@freebsd.org|ema...@freebsd.org -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #3 from commit-h...@freebsd.org --- A commit references this bug: Author: emaste Date: Wed Apr 17 17:00:16 UTC 2019 New revision: 346323 URL: https://svnweb.freebsd.org/changeset/base/346323 Log: readelf: speed up readelf -wo Use an array instead of STAILQ, and sort at the end instead of while adding new elements. PR: 212539 Submitted by: Bora ?zarslan Reviewed by: markj MFC after:2 weeks Sponsored by: The FreeBSD Foundation Changes: head/contrib/elftoolchain/readelf/readelf.c -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 Ed Maste changed: What|Removed |Added Blocks||231027 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231027 [Bug 231027] [META] FreeBSD-Foundation sponsored issues for FreeBSD 13-CURRENT -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 --- Comment #2 from Mark Johnston --- It's elftoolchain. The issue is still reproducible with at least gcc 6. -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
[Bug 212539] readelf -w consumes a lot of memory with GCC-compiled kernels
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212539 Bug ID: 212539 Summary: readelf -w consumes a lot of memory with GCC-compiled kernels Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-b...@freebsd.org Reporter: ma...@freebsd.org CC: freebsd-amd64@FreeBSD.org CC: freebsd-amd64@FreeBSD.org I tried compiling a kernel with both gcc48 and gcc6 and hit the same problem with both. Running readelf -w against kernel.full causes it to emit a bunch of errors: $ readelf -w kernel.full >/dev/null readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)] readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)] readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)] readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)] readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)] readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)] readelf: dwarf_loclist_form_expr_b: Invalid location expression [_dwarf_loc_fill_locdesc(632)] and it seemingly runs forever while consuming ever-increasing amounts of memory: 2558 markj 1030 3615M 3591M CPU00 2:07 97.33% readelf -w kernel.full -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-amd64@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
