https://sourceware.org/bugzilla/show_bug.cgi?id=25665
--- Comment #3 from Tamar Christina ---
This is a difficult one since I don't think we can solve the general problem
without having some compiler support here.
Do you in your big text section is it really one big function like your
example?
https://sourceware.org/bugzilla/show_bug.cgi?id=19104
Nick Clifton changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://sourceware.org/bugzilla/show_bug.cgi?id=25677
--- Comment #10 from Nick Clifton ---
(In reply to Stephen Casner from comment #9)
Hi Stephen,
> Another solution, perhaps the most straightforwad one, would be to change
> the code in adjust_o_magic() to not pad the size of the data section
https://sourceware.org/bugzilla/show_bug.cgi?id=25750
--- Comment #7 from Nick Clifton ---
(In reply to Jian Cai from comment #6)
Hi Jian,
> I made an LLVM patch for (https://reviews.llvm.org/D76962), which will make
> clang's integrated assembler to treat .inst and its arguments as one macro
>
https://sourceware.org/bugzilla/show_bug.cgi?id=25295
H.J. Lu changed:
What|Removed |Added
Attachment #12442|0 |1
is obsolete|
https://sourceware.org/bugzilla/show_bug.cgi?id=20070
--- Comment #12 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Rainer Orth :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3e97ba7d583055bdd5439dd300c59a2f5bc02476
commit 3e97ba7d583055bdd5439dd300c
https://sourceware.org/bugzilla/show_bug.cgi?id=25665
--- Comment #4 from rrorden at ptc dot com ---
We develop a Java Virtual Machine and tools, including an ahead-of-time
compiler to generate native code from Java bytecode. The output of that tool is
an ELF object with .rela.text, .text, .rodata
https://sourceware.org/bugzilla/show_bug.cgi?id=25665
--- Comment #5 from Tamar Christina ---
It works on AArch32 because it places the veneers directly after the input
section instead of after all sections.
This is just a coincidence that it works, the general problem doesn't work,
You can get
https://sourceware.org/bugzilla/show_bug.cgi?id=25665
--- Comment #6 from rrorden at ptc dot com ---
I understand now. Thanks for the explanation. For now I have found a workaround
for my problem with a large aot-compiled object by custom-naming the ELF
sections and using a linker script to order
https://sourceware.org/bugzilla/show_bug.cgi?id=25665
--- Comment #7 from Tamar Christina ---
> If I implement the equivalent of -ffunction-sections, would this cause the
> image expansion problem for A53 erratum you mentioned?
I think `-ffunction-sections` alone won't help you on AArch64. It
https://sourceware.org/bugzilla/show_bug.cgi?id=25665
--- Comment #8 from rrorden at ptc dot com ---
So the proposal is to add an aarch64 linker option that places stubs after
input sections that need them, just like aarch32, and I would need to implement
the -ffunction-sections behavior in our ao
https://sourceware.org/bugzilla/show_bug.cgi?id=25784
Fangrui Song changed:
What|Removed |Added
CC||amodra at gmail dot com
--
You are re
https://sourceware.org/bugzilla/show_bug.cgi?id=24685
--- Comment #3 from Jim Wilson ---
This is on my todo list along with hundreds of other things. I don't know of
any reason why this needs priority attention, so it may be a while before I
have a chance to work on it.
--
You are receiving th
https://sourceware.org/bugzilla/show_bug.cgi?id=25665
Wilco changed:
What|Removed |Added
CC||wdijkstr at arm dot com
--- Comment #9 from W
https://sourceware.org/bugzilla/show_bug.cgi?id=25665
--- Comment #10 from rrorden at ptc dot com ---
(In reply to Wilco from comment #9)
> You don't need to place every function in its own section (that would add a
> lot of overhead if there are millions), just avoid creating sections larger
> t
https://sourceware.org/bugzilla/show_bug.cgi?id=25665
--- Comment #11 from Tamar Christina ---
(In reply to rrorden from comment #8)
> So the proposal is to add an aarch64 linker option that places stubs after
> input sections that need them, just like aarch32, and I would need to
> implement the
16 matches
Mail list logo