https://sourceware.org/bugzilla/show_bug.cgi?id=18625
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
Assignee: unassigned at sourceware dot org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
I noticed this by accident. The x86 assembler has a -n option which says to
emit one byte nops instead of multi-byte nops. But when I try it, it doesn't
work.
rohan:2162
: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Created attachment 10624
--> https://sourceware.org/bugzilla/attachment.cgi?id=10624&action=edit
Proposed fix
https://sourceware.org/bugzilla/show_bug.cgi?id=22465
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=22465
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
||wilson at gcc dot gnu.org
Resolution|--- |FIXED
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
--- Comment #2 from Jim Wilson ---
Patch committed to mainline.
--
You are receiving this mail because:
You are on
||2018-01-08
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils
https://sourceware.org/bugzilla/show_bug.cgi?id=22598
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=22598
--- Comment #2 from Jim Wilson ---
Note that the testcase is trying to use absolute addresses with a pc-relative
branch. The assembler can't know the address the linker will assign to the
code, so this requires a relocation. I don't know if
https://sourceware.org/bugzilla/show_bug.cgi?id=22598
--- Comment #4 from Jim Wilson ---
I would expect this to work
.option norelax
beq s1, s0, .+102
bne a4, a5, .-4096
jal a2, 1048574
I get
<.L0 >:
0: 06848363beq s1,s0,66 <.L0 +0
https://sourceware.org/bugzilla/show_bug.cgi?id=22598
--- Comment #6 from Jim Wilson ---
The address printed for jal is nonsense because it has a reloc, but the address
for the branches should be correct.
I think the problem with the is that we have two ".L0 " fake symbols,
and objdump is using
https://sourceware.org/bugzilla/show_bug.cgi?id=22598
--- Comment #8 from Jim Wilson ---
Branches work the same way on RISC-V as they do on MIPS. Here is a mips
example to show that.
rohan:2123$ cat tmp.s
_start:
.skip 4096
beq $6, $7, 100
bne $4, $5, 4096
.skip
https://sourceware.org/bugzilla/show_bug.cgi?id=22598
--- Comment #11 from Jim Wilson ---
You must be careful when interpreting an unrelocated object file. The
relocation
0: R_MIPS_PC16 *ABS*
makes it clear that you have a zero-based absolute address in the branch.
The disassembler is
https://sourceware.org/bugzilla/show_bug.cgi?id=22756
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=22756
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=15904
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=15904
--- Comment #3 from Jim Wilson ---
The patch looks mostly correct, but we should be setting changed_contents also.
The patch looks small enough and obvious enough that I don't think that we
need a copyright assignment for the provided patch.
https://sourceware.org/bugzilla/show_bug.cgi?id=15904
--- Comment #5 from Jim Wilson ---
Updated patch committed.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://li
https://sourceware.org/bugzilla/show_bug.cgi?id=15904
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=22903
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=22756
--- Comment #4 from Jim Wilson ---
I found another problem with linker relaxation and symbol sizes.
gamma05:2463$ cat tmp.c
extern void sub3 (void);
void __attribute__ ((noinline))
sub2 (void)
{
sub3 ();
}
void __attribute__ ((noinline))
https://sourceware.org/bugzilla/show_bug.cgi?id=22903
--- Comment #7 from Jim Wilson ---
I don't particularly care how this gets fixed.
Your patch seems to have a flaw. You are skipping over the first 4 bytes of
the stub if it isn't aligned, but you aren't increasing the size of the stub to
all
||2018-03-06
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
Your linker script sets the output format to binary. Unfortunately, the
current RISC-V linker only works for ELF
https://sourceware.org/bugzilla/show_bug.cgi?id=22920
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=22920
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
||2018-03-09
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
I just got the same bug report for a riscv* target. I can reproduce this
failure for any target by forcing intl
https://sourceware.org/bugzilla/show_bug.cgi?id=22945
--- Comment #1 from Jim Wilson ---
I don't have any easy way to look at this. I don't have access to an
ia64-linux machine. Ubuntu doesn't have an ia64-linux cross compiler. And the
visibility tests are not run for ia64-elf. So I'd have to
https://sourceware.org/bugzilla/show_bug.cgi?id=22962
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=22962
--- Comment #3 from Jim Wilson ---
I have a Fedora stage4 disk image that I'm running on qemu, and which has
glibc-2.27. Libraries are in /usr/lib64 exactly as I expect.
You pointed at part 0 of a 19 part patch set. I'm guessing you are tal
https://sourceware.org/bugzilla/show_bug.cgi?id=22962
--- Comment #4 from Jim Wilson ---
Note that gcc has
#define STARTFILE_PREFIX_SPEC \
"/lib" XLEN_SPEC "/" ABI_SPEC "/ " \
"/usr/lib" XLEN_SPEC "/" ABI_SPEC "/ " \
"/lib/ "
https://sourceware.org/bugzilla/show_bug.cgi?id=22962
--- Comment #5 from Jim Wilson ---
I need more info. How was gcc configured? What are the options that gcc is
passing to the linker? How are the libraries structured? What is in /usr/lib
for instance. What OS and distro is this? If this
https://sourceware.org/bugzilla/show_bug.cgi?id=22962
--- Comment #7 from Jim Wilson ---
DJ Delorie provided some helpful info about Fedora RISC-V port in a chat and
I'm now starting to understand the problem. Turns out that Fedora does put
libraries in /usr/lib64/lp64d, and then puts links in /
https://sourceware.org/bugzilla/show_bug.cgi?id=22962
--- Comment #8 from Jim Wilson ---
If gcc is configured --enable-multilib, then it appears that you get the -L
options you need for this to work. If gcc is configured --disable-multilib,
then you do not get the -L options needed for this to w
https://sourceware.org/bugzilla/show_bug.cgi?id=22962
--- Comment #11 from Jim Wilson ---
(In reply to jos...@codesourcery.com from comment #10)
> Again, the quoted error is about a search that uses -rpath-link paths but
> *not* -L paths. GCC uses the right -L paths automatically, but
> LIBPAT
https://sourceware.org/bugzilla/show_bug.cgi?id=22941
--- Comment #3 from Jim Wilson ---
There is no fix in the PR. The list of files is just showing that plural.c is
the only bison output file in the git tree.
The glibc solution is to drop the generated file from the git tree, and always
gener
https://sourceware.org/bugzilla/show_bug.cgi?id=22962
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://sourceware.org/bugzilla/show_bug.cgi?id=22962
--- Comment #15 from Jim Wilson ---
I've posted a proposed patch for review
https://sourceware.org/ml/binutils/2018-05/msg00043.html
And there is also a gcc part as it adds new linker emulations
https://gcc.gnu.org/ml/gcc-patches/2018-
|--- |FIXED
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
--- Comment #17 from Jim Wilson ---
Patch on mainline.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug
||2018-05-24
CC||wilson at gcc dot gnu.org
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
I see several problems
https://sourceware.org/bugzilla/show_bug.cgi?id=23219
Jim Wilson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2018-05-30
CC||wilson at gcc dot gnu.org
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
I see the problem. This is
https://sourceware.org/bugzilla/show_bug.cgi?id=22756
--- Comment #8 from Jim Wilson ---
Linker relaxation that deletes code is O(m*n) where m is the number of
relocations and n is the number of symbols. There have been complaints about
this. This makes the RISC-V linker slower than other targe
https://sourceware.org/bugzilla/show_bug.cgi?id=23244
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=23305
--- Comment #2 from Jim Wilson ---
lla is only valid for symbol addresses. It isn't meant to be used for
constants. But that is an interesting testcase. Did this come from real code?
If so then we need to fix this.
You can make medlow fai
https://sourceware.org/bugzilla/show_bug.cgi?id=23305
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||2018-07-27
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jim Wilson ---
I did a build test, but I see now that it builds but doesn't run. Annoying,
but this is easy to fi
https://sourceware.org/bugzilla/show_bug.cgi?id=23451
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=23825
--- Comment #1 from Jim Wilson ---
This is a feature of the RISC-V toolchain, which apparently isn't supported by
any other toolchain, and which is known to be broken, but we don't yet know if
it is a gcc, binutils, ld.so, or something else bu
https://sourceware.org/bugzilla/show_bug.cgi?id=23825
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
||2018-12-07
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
I consider it a bug, but not serious enough that I had gotten around to trying
to fix it yet. The
https://sourceware.org/bugzilla/show_bug.cgi?id=23956
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2018-12-08
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
The problem is the extra register, not the unknown relocation function. I get
the same error with
https://sourceware.org/bugzilla/show_bug.cgi?id=23954
Jim Wilson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=24226
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=24226
--- Comment #2 from Jim Wilson ---
Another possibility here is a broken linker script that isn't respecting
section alignment.
--
You are receiving this mail because:
You are on the CC list for the bug.
__
https://sourceware.org/bugzilla/show_bug.cgi?id=24226
--- Comment #4 from Jim Wilson ---
Yes, I'd call this a compiler bug. It is triggered when we have a long long
inside a packed structure compiled for a 32-bit target, where the long long
must be partially contained in the first word of the st
||2019-03-20
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
I never tried this with a global symbol. This only works for local symbols.
sym is only set for local
https://sourceware.org/bugzilla/show_bug.cgi?id=24365
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=24389
--- Comment #1 from Jim Wilson ---
David Abdurachmanov reported the same problem with Fedora over the weekend, but
I wasn't able to look at it at the time as SiFive building power was off for
maintenance.
Building glib to reproduce, I see tha
https://sourceware.org/bugzilla/show_bug.cgi?id=24389
--- Comment #4 from Jim Wilson ---
I don't see a way to specify this in the linker either.
I looked at gas, and noticed that it is broken also, but slightly differently.
Gas is defaulting to rv64g/lp64d when configured for 64-bit, and rv32g/
https://sourceware.org/bugzilla/show_bug.cgi?id=24389
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24389
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=24426
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=24426
--- Comment #3 from Jim Wilson ---
I tried to reproduce with no luck. I think that there are too many things
broken on your end. I had to hack up crt0.S to remove the required support for
__global_pointer$, and I had to hack your linker scri
https://sourceware.org/bugzilla/show_bug.cgi?id=24426
--- Comment #7 from Jim Wilson ---
An empty linker script isn't expected to work. This will probably fail for
every linker target. It fails for x86_64-linux for instance.
rohan:2037$ uname -a
Linux rohan 4.15.0-47-generic #50-Ubuntu SMP Wed
https://sourceware.org/bugzilla/show_bug.cgi?id=24426
--- Comment #9 from Jim Wilson ---
RISC-V is an ISA. The amount of memory that can be accessed depends on the ISA
implementation that you are using. This varies from one implementation to
another. But most 64-bit processors do not have 64 a
||2019-06-12
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
The DTPMOD64 reloc is required for a shared library, and a PIE program is
basically a shared library with a few
https://sourceware.org/bugzilla/show_bug.cgi?id=24673
--- Comment #2 from Jim Wilson ---
The issue with the R_RISCV_NONE appears to be that we are pre-allocating space
for dynamic relocs, and accidentally allocating one more than we need. This
space is apparently cleared someplace. So it ends u
https://sourceware.org/bugzilla/show_bug.cgi?id=24673
--- Comment #3 from Jim Wilson ---
Via IRC, elfnn-riscv.c circa line 563 has
case R_RISCV_TLS_GOT_HI20:
if (bfd_link_pic (info))
info->flags |= DF_STATIC_TLS;
where this should be bfd_link_dll instead of bfd_link_
||2019-06-13
CC||wilson at gcc dot gnu.org
Depends on||24673
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
Assuming that the MIPS port is handling this right, then
https://sourceware.org/bugzilla/show_bug.cgi?id=24673
Jim Wilson changed:
What|Removed |Added
Blocks||24676
Referenced Bugs:
https://sourcew
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Reported via IRC.
Compiling a trivial program as PIE, I get
hifiveu017:1201$ gcc -pie -fpic tmp.c
hifiveu017:1202$ readelf -s a.out | grep global_pointer
65
https://sourceware.org/bugzilla/show_bug.cgi?id=24678
Jim Wilson changed:
What|Removed |Added
Target||riscv*-*-*
--
You are receiving this ma
https://sourceware.org/bugzilla/show_bug.cgi?id=24678
--- Comment #1 from Jim Wilson ---
The section for linker script defined variables is set in set_sym_sections, via
update_definedness, which uses section_for_dot.
Since we are computing the __global_pointer$ value near the end of the linker
s
Assignee: unassigned at sourceware dot org
Reporter: wilson at gcc dot gnu.org
Target Milestone: ---
Another one from the lld folks.
Given
.global test, foo, bar, baz
test:
call foo
call bar
call bar@plt
call baz@plt
and compiling it with
gcc -o call-plt
||2019-06-25
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
Looks like the problem is in riscv_elf_finish_dynamic_symbol where we have
/* If the symbol is weak, we
https://sourceware.org/bugzilla/show_bug.cgi?id=24739
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=24739
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=22941
Jim Wilson changed:
What|Removed |Added
CC||pjb at informatimago dot com
--- Comment
||wilson at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Jim Wilson ---
Duplicate of 22941. intl does't build with bison-3.0.4.
*** This bug has been marked as a duplicate of bug 22941 ***
--
You are receiving this mail be
https://sourceware.org/bugzilla/show_bug.cgi?id=23825
--- Comment #3 from Jim Wilson ---
I got an internal bug report with a simplified testcase related to this, took
another look, and found the problem.
hifiveu017:1097$ cat tmp.c
#include
extern __thread int a;
int main (void) {printf ("a = %d
https://sourceware.org/bugzilla/show_bug.cgi?id=23825
Jim Wilson changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #5 from Jim Wilson
||2019-09-10
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson ---
Commentary copied from the gcc bug report...
This is an edge condition and an accident of circumstances. When
https://sourceware.org/bugzilla/show_bug.cgi?id=24992
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
||wilson at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Jim Wilson ---
the problem is that you are using objdump -D, and this is almost always the
wrong thing to do. The correct option is "-d".
-D will dump data sections
https://sourceware.org/bugzilla/show_bug.cgi?id=24983
Jim Wilson changed:
What|Removed |Added
CC||yitingwang16 at outlook dot com
--- Comm
https://sourceware.org/bugzilla/show_bug.cgi?id=24992
Jim Wilson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=24992
--- Comment #4 from Jim Wilson ---
It is the same underlying problem. Addresses can increase by up to section
alignment after relaxation, so we have to reduce gp range by the alignment of
the largest section in between gp and the variable, bu
https://sourceware.org/bugzilla/show_bug.cgi?id=24983
--- Comment #3 from Jim Wilson ---
There is another related problem reported here
https://github.com/riscv/riscv-gnu-toolchain/issues/497
--
You are receiving this mail because:
You are on the CC list for the bug.
___
https://sourceware.org/bugzilla/show_bug.cgi?id=24993
Jim Wilson changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://sourceware.org/bugzilla/show_bug.cgi?id=24992
--- Comment #6 from Jim Wilson ---
See comment #4 that says "Unless gp and the variable are in the same section,
in which case we can ignore the problem."
--
You are receiving this mail because:
You are on the CC list for the bug.
__
||2019-11-12
CC||wilson at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Jim Wilson ---
The way that this should work is that if the call crosses section boundaries,
then we need to use the max
https://sourceware.org/bugzilla/show_bug.cgi?id=25181
--- Comment #5 from Jim Wilson ---
Created attachment 12071
--> https://sourceware.org/bugzilla/attachment.cgi?id=12071&action=edit
untested patch to fix _bfd_riscv_relax_call
--
You are receiving this mail because:
You are on the CC list
https://sourceware.org/bugzilla/show_bug.cgi?id=25181
--- Comment #6 from Jim Wilson ---
You can create a patch with git diff and then attach it to the bug report. It
needs to be mailed to the binutils list if it gets checked in, but you can
always ask someone else to do that for you.
Contribut
|--- |FIXED
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
--- Comment #9 from Jim Wilson ---
Fixed on mainline.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=23825
--- Comment #9 from Jim Wilson ---
This is being discussed in
https://github.com/riscv/riscv-elf-psabi-doc/issues/122
which is the proper place to discuss RISC-V ABI issues.
--
You are receiving this mail because:
You are on the CC list f
https://sourceware.org/bugzilla/show_bug.cgi?id=25264
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=25258
Jim Wilson changed:
What|Removed |Added
CC||wilson at gcc dot gnu.org
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=25205
--- Comment #2 from Jim Wilson ---
I made an attempt to reproduce this, but I don't build llvm very often (cough)
so I don't really know what I'm doing. I can build llvm in a one stage build
on a riscv fedora system. When I tried a two stage
https://sourceware.org/bugzilla/show_bug.cgi?id=25205
--- Comment #7 from Jim Wilson ---
I can reproduce with your object files. I had to add a -B option to find
crtbegin.o and libgcc.a. Maybe something wrong with clang on my system.
Anyways, what I see is that in _bfd_riscv_relax_section, if
1 - 100 of 140 matches
Mail list logo
