https://sourceware.org/bugzilla/show_bug.cgi?id=21303
--- Comment #3 from cvs-commit at gcc dot gnu.org ---
The binutils-2_28-branch branch has been updated by Alan Modra
:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=95afaad6b0419b5de31a7759c8c37485b7dd78ff
commit 95afaad6b0419b5
Hi,
I am porting binutils to my new architecture. I have made changes similar
to one of the architecture which GNU binutils already supports.
I am also able to do testing of binutils using dejaGNU. But, there are few
options for which I am stuck up and not able to test these options. These
are as
https://sourceware.org/bugzilla/show_bug.cgi?id=21319
Bug ID: 21319
Summary: readelf --debug-dump=gdb_index fails to dump valid
address tables
Product: binutils
Version: 2.28
Status: UNCONFIRMED
Severity: normal
https://sourceware.org/bugzilla/show_bug.cgi?id=18025
--- Comment #13 from Jon Turney ---
(In reply to Nick Clifton from comment #11)
> Have you tried using the latest binutils ? We did make some improvements to
> line number caching recent. (Although I think that this was with DWARF not
> STAB
https://sourceware.org/bugzilla/show_bug.cgi?id=18025
--- Comment #12 from Jon Turney ---
Created attachment 9949
--> https://sourceware.org/bugzilla/attachment.cgi?id=9949&action=edit
example of a large object file demonstrating 'nm -l' slowdown
--
You are receiving this mail because:
You ar
https://sourceware.org/bugzilla/show_bug.cgi?id=21233
Maciej W. Rozycki changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #14 from Mac
https://sourceware.org/bugzilla/show_bug.cgi?id=21303
--- Comment #2 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=9b7539374617a94c2d646f49e1bbfc954b11891d
commit 9b7539374617a94c2d646f49e1bbf
https://sourceware.org/bugzilla/show_bug.cgi?id=18025
--- Comment #11 from Nick Clifton ---
Hi Jon,
> Looking at the commit, even if the object isn't rebased, every symbol without
> linenumber information (e.g. type 'N' symbols) will cause an exhaustive,
> linear search for the symbol (I guess l
