https://sourceware.org/bugzilla/show_bug.cgi?id=15835
Richard PALO changed:
What|Removed |Added
CC||richard at netbsd dot org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=15835
--- Comment #9 from Richard PALO ---
For a very simpistic test, I have an existing thunderbird libxul.so which, with
which the currently installed binutils readelf gives:
>richard@omnis:/tmp/pkgsrc/devel/binutils/work/binutils-2.25.1/binutils$
https://sourceware.org/bugzilla/show_bug.cgi?id=15835
--- Comment #10 from Richard PALO ---
I did try two things in addition...
First, and again with the existing libxul.so:
>$ gobjdump -T /opt/local/lib/thunderbird24/libxul.so
>
>/opt/local/lib/thunderbird24/libxul.so: file format elf32-i38
https://sourceware.org/bugzilla/show_bug.cgi?id=15835
--- Comment #12 from Richard PALO ---
they are quite large:
> $ gls -sh pr15835.libxuls.tar.bz2
> 676M pr15835.libxuls.tar.bz2
can I copy them somewhere in particular?
I could also do one at a time which is half the size.
--
You are receiv
https://sourceware.org/bugzilla/show_bug.cgi?id=15835
--- Comment #14 from Richard PALO ---
sorry, my habitual large file site no longer likes FF24...
this link will only be valid for about a week: http://tnow.it/82kx31b6uncf
--
You are receiving this mail because:
You are on the CC list for t
https://sourceware.org/bugzilla/show_bug.cgi?id=15835
--- Comment #16 from Richard PALO ---
Comment on attachment 8625
--> https://sourceware.org/bugzilla/attachment.cgi?id=8625
Extended patch
are all these sim/* bits applicable or by accident they are included?
--
You are receiving this mai
https://sourceware.org/bugzilla/show_bug.cgi?id=15835
--- Comment #18 from Richard PALO ---
great, both greadelf and gobjdump seem fine with libxul.so now
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils ma
https://sourceware.org/bugzilla/show_bug.cgi?id=19520
Richard PALO changed:
What|Removed |Added
CC||richard at netbsd dot org
--- Comment
: gas
Assignee: unassigned at sourceware dot org
Reporter: richard at netbsd dot org
Target Milestone: ---
Created attachment 8958
--> https://sourceware.org/bugzilla/attachment.cgi?id=8958&action=edit
intermediate assembler file
Having applied the patch for ga
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
--- Comment #1 from Richard PALO ---
Created attachment 8959
--> https://sourceware.org/bugzilla/attachment.cgi?id=8959&action=edit
the respective gas output file
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
--- Comment #3 from Richard PALO ---
(In reply to H.J. Lu from comment #2)
> I built a cross binutils to x86_64-solaris2 on Linux/x86-64 and got
>
> [hjl@gnu-tools-1 gas]$ nm -lug x.o | grep ree
> U __dtrace_Xserver___resource__free
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
--- Comment #5 from Richard PALO ---
(In reply to H.J. Lu from comment #4)
> The difference is
> -64: 0 NOTYPE GLOBAL DEFAULT OS [0xff3f]
> __dtrace_Xserver___resour
> +64: 0 NOTYPE GLOBAL DEFAULT UND __dtr
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
Richard PALO changed:
What|Removed |Added
Status|WAITING |SUSPENDED
--- Comment #7 from Richard
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
--- Comment #8 from Richard PALO ---
Finally found the time to confirm that it is indeed the dtrace utility causing
the problem and not gas (although gas may be generating objects not yet
understood correctly in dtrace).
>From dix/Makefile:
>
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
--- Comment #9 from Richard PALO ---
I believe the issue comes down to dtrace updating its symbol from
'__dtrace_Xserver___resource__free' to '__dtrace_Xserver___resource-free'
given that the input object file's strtab doesn't have a separate
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
--- Comment #10 from Richard PALO ---
Since this affects, in principle, *any* dtrace implementation including *bsd,
linux, ... I'm inclined to ask the question whether there is any way to force
ELF symtab generation *not* to optimise with sub
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
--- Comment #12 from Richard PALO ---
I was referring to the code generation (here, .symtbl) change between 2.25.1
and 2.26.0 where the problem became apparent...
It would be useful to have a means to enforce the previous behaviour (read:
whi
17 matches
Mail list logo
