[Bug binutils/29785] memory bloat in version 2.39

2023-10-03 Thread joelhock at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=29785

Joel Hock  changed:

   What|Removed |Added

 CC||joelhock at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28588] significant performance regression in addr2line

2022-07-12 Thread joelhock at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28588

Joel Hock  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Joel Hock  ---
I re-tested, and this is fixed by 30cbd32aec3.  I'm closing this out as
resolved / fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28834] incorrect detection of "DWARF error: section .debug_str is larger than its filesize"

2022-02-01 Thread joelhock at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28834

--- Comment #2 from Joel Hock  ---
I can't upload the binary, but the uncompressed size (b6e3fb5 in the output
below) is correct.  This output is from a different, but similar, binary than
what was generating the original error message I posted:

$ readelf -t mybinary
  [Nr] Name
   Type  Address  OffsetLink
   Size  EntSize  Info  Align
   Flags
...
  [38] .debug_str
   PROGBITS   07259234  0
   01a18720 0001  0 1
   [0830]: MERGE, STRINGS, COMPRESSED
   ZLIB, 0b6e3fb5, 1

A 10x heuristic would have worked in this case, fwiw.

Joel

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28834] New: incorrect detection of "DWARF error: section .debug_str is larger than its filesize"

2022-01-28 Thread joelhock at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28834

Bug ID: 28834
   Summary: incorrect detection of "DWARF error: section
.debug_str is larger than its filesize"
   Product: binutils
   Version: 2.37
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: joelhock at gmail dot com
  Target Milestone: ---

Commit 647cebce12a can cause valid sections to be considered corrupt if their
uncompressed size is greater than the size of the entire binary, resulting in
warnings like:

addr2line: DWARF error: section .debug_str is larger than its filesize!
(0xb60c570 vs 0x9309705)

One example binary we have is 150MB total; however, the .debug_str section is
190MB uncompressed (and only 27MB compressed).  I’m not sure what the best fix
is to keep the protection of intended by the commit without causing these false
positives.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


[Bug binutils/28588] New: significant performance regression in addr2line

2021-11-12 Thread joelhock at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=28588

Bug ID: 28588
   Summary: significant performance regression in addr2line
   Product: binutils
   Version: 2.38 (HEAD)
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: binutils
  Assignee: unassigned at sourceware dot org
  Reporter: joelhock at gmail dot com
  Target Milestone: ---

Commit ca8f6bc629c causes a significant performance issue for my use of
addr2line.  Specifically, the use of lookup_func_by_offset() exhibits quadratic
complexity when processing a new compile unit.  One of our larger compile units
has 80k entries in the funcinfo table, many of which I believe come from C++
inlined subroutines.  This takes almost 20 seconds to process, whereas before
this commit, processing the compile unit was nearly instantaneous.  The
regression is especially felt when using a tool such as google-pprof, which
queries addresses across many compile units; what used to take 1 minute before
that commit now takes 10.

-- 
You are receiving this mail because:
You are on the CC list for the bug.