https://sourceware.org/bugzilla/show_bug.cgi?id=20360
--- Comment #9 from H.J. Lu ---
Please provide the smallest set of linker inputs which can reproduce
the problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug
https://sourceware.org/bugzilla/show_bug.cgi?id=20360
--- Comment #8 from Peter Jas ---
Here is the corresponding linker command (without -BSymbolic* , when I ran
clang++ command with -v in
coreclr/bin/obj/Linux.x64.Debug/src/dlls/mscoree/coreclr directory):
"/usr/bin/ld" -z now -z relro --hash-
https://sourceware.org/bugzilla/show_bug.cgi?id=20360
--- Comment #7 from H.J. Lu ---
I need the linker input so that I can reproduce the linker output.
Binary inputs are OK.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=20360
--- Comment #6 from Rich Felker ---
To add some context, I suggested building without -Bsymbolic* in case the cause
was relocations that would be textrels before -Bsymbolic* optimized them out.
Looking at the source, particularly calls/jmps to
https://sourceware.org/bugzilla/show_bug.cgi?id=20360
--- Comment #5 from Peter Jas ---
Thanks Rich. I am not the dotnet folk per-se; just contributed some port
related PR to the coreclr repo and such. Should we ping someone on the GitHub
issue if more information is required?
I have uploaded tw
https://sourceware.org/bugzilla/show_bug.cgi?id=20360
--- Comment #4 from Peter Jas ---
Created attachment 9386
--> https://sourceware.org/bugzilla/attachment.cgi?id=9386&action=edit
"readelf -aW libcoreclr.so" dump (without -XLinker -BSymbolic -XLinker
-BSymbolic-functions)
readelf output of
https://sourceware.org/bugzilla/show_bug.cgi?id=20360
--- Comment #3 from Rich Felker ---
At this point there's no testcase smaller than the dotnet/coreclr build, but I
wanted to go ahead and post the bug here to get discussion moved to the tracker
where it's relevant. I believe they have a way t
https://sourceware.org/bugzilla/show_bug.cgi?id=20360
Peter Jas changed:
What|Removed |Added
CC||danglingpointer at live dot com
--- Comme
https://sourceware.org/bugzilla/show_bug.cgi?id=20360
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://sourceware.org/bugzilla/show_bug.cgi?id=20360
Bug ID: 20360
Summary: DT_TEXTREL appearing in output with no textrels on
x86_64
Product: binutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
--- Comment #13 from H.J. Lu ---
(In reply to Richard PALO from comment #12)
> 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
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
https://sourceware.org/bugzilla/show_bug.cgi?id=19576
--- Comment #11 from H.J. Lu ---
(In reply to Richard PALO from comment #10)
> 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
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
14 matches
Mail list logo
