[Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols
--- Additional Comments From nickc at redhat dot com 2008-10-09 12:55 --- Created an attachment (id=2985) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2985&action=view) Add libiberty.a to the shared lib adds -- http://sourceware.org/bugzilla/show_bug.cgi?id=6937 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/6937] binutils 2.18 fails linking libopcodes.so due to missing symbols
--- Additional Comments From nickc at redhat dot com 2008-10-09 12:57 --- Hi Peter, Thanks for mentioning --enable-shared. That was the flag that I was missing when I tried the test the first time. I can now reproduce the problem and I have a patch for you to try out. If it works for you let me know and I will check it in. Cheers Nick -- http://sourceware.org/bugzilla/show_bug.cgi?id=6937 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6945] ld -r severely broken on 64-bit mingw / pe-x86-64
--- Additional Comments From nickc at redhat dot com 2008-10-09 13:23 --- Hi Mikael, So - what is the difference between bug.o and bug2.o ? Is it possible to reproduce the bug without using inline assembly ? Cheers Nick -- What|Removed |Added Status|NEW |WAITING http://sourceware.org/bugzilla/show_bug.cgi?id=6945 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/6945] ld -r severely broken on 64-bit mingw / pe-x86-64
--- Additional Comments From mikpe at it dot uu dot se 2008-10-09 15:02
---
(In reply to comment #1)
> Hi Mikael,
>
> So - what is the difference between bug.o and bug2.o ?
objdump -h bug*.o
bug.o: file format pe-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00a0 00b4 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 2**4
ALLOC, LOAD, DATA
2 .bss 2**4
ALLOC
3 .rdata0050 0154 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
bug2.o: file format pe-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00a0 00b4 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00a0 00a0 2**4
ALLOC, LOAD, DATA
2 .rdata0050 00a0 00a0 0154 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
3 .bss 00f0 00f0 2**4
ALLOC
The files are the same size, but ld -r changes the order of the sections, and
appears to add the size of .text (0x0a) to the VMA/LMA of .data and .rdata.
And the offsets in the jump table are also off by 0x0a, but since the code and
the jump table haven't moved the jump table targets are now wrong.
> Is it possible to reproduce the bug without using inline assembly ?
Certainly, it's just a gcc switch() jump table. I used inline asm in order to
write a test program that could inspect and verify the jump table instead of
crashing. The program below (cbug.c) shows the bug in plain C:
x86_64-pc-mingw32-gcc -O -c cbug.c
x86_64-pc-mingw32-ld -r -o cbug2.o cbug.o
x86_64-pc-mingw32-gcc -o cbug cbug.o
x86_64-pc-mingw32-gcc -o cbug2 cbug2.o
./cbug
at state 0
at state 1
at state 2
at state 3
at state 4
at state 5
at state 6
at state 7
2173
echo $?
0
./cbug2
at state 0
echo $?
128
Running cbug2 in gdb confirms that it branches to la-la land the first time it
enters the switch(), and then SEGVs.
#include
enum state { q0, q1, q2, q3, q4, q5, q6, q7 };
int run(int x)
{
enum state state = q0;
for (;;) {
printf("at state %d\n", state);
fflush(stdout);
switch (state) {
case q0: x += 1; state = q1; continue;
case q1: x *= 2; state = q2; continue;
case q2: x += 3; state = q3; continue;
case q3: x *= 4; state = q4; continue;
case q4: x += 5; state = q5; continue;
case q5: x *= 6; state = q6; continue;
case q6: x += 7; state = q7; continue;
case q7: return x;
}
}
}
int main(void)
{
printf("%d\n", run(42));
return 0;
}
--
http://sourceware.org/bugzilla/show_bug.cgi?id=6945
--- You are receiving this mail because: ---
You are on the CC list for the bug, or are watching someone who is.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/6944] GNU as manual / GNU as itself is incorrect about dollar local labels
--- Additional Comments From nickc at redhat dot com 2008-10-09 15:10 --- Created an attachment (id=2987) --> (http://sourceware.org/bugzilla/attachment.cgi?id=2987&action=view) Fix documentation -- http://sourceware.org/bugzilla/show_bug.cgi?id=6944 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/6944] GNU as manual / GNU as itself is incorrect about dollar local labels
--- Additional Comments From nickc at redhat dot com 2008-10-09 15:12 --- Hi Miro, Thanks for catching this. I am going to apply the uploaded patch to fix the documentation. Cheers Nick gas/ChangeLog 2008-10-09 Nick Clifton <[EMAIL PROTECTED]> PR 6944 * doc/as.texinfo (Dollar Local Labels): Correct description of dollar local labels to show that the colon suffix is still needed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://sourceware.org/bugzilla/show_bug.cgi?id=6944 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/6944] GNU as manual / GNU as itself is incorrect about dollar local labels
--- Additional Comments From miro dot kropacek at gmail dot com 2008-10-09 17:02 --- Hi, no problem. Actually, I was going to submit a patch which respects the LABELS_WITHOUT_COLONS settings also for n$: and n: labels to the source code :) It's part of bigger patch I'm working on so it's OK to fix this in documentation for now. -- http://sourceware.org/bugzilla/show_bug.cgi?id=6944 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/6956] New: When in MRI mode, local labels don't work correctly
Take this example code (m68k, MRI mode) xxxglob: dc.w-1 1: nop bra.b 1f ffxxx: dc.w-2 1: nop bra.b 1b it assembles into this: ff ff (-1) 4e 71 (nop) 60 02 (bra.b +2 bytes) ff fe (-2) 4e 71 (nop) 60 f5 (bra -11 bytes, wtf?! it should be bra -2 bytes here!) ab cd (0xabcd) I tested it even on old gas 2.13 and this bug is here... strange nobody noticed it. It happens only when in MRI mode. -- Summary: When in MRI mode, local labels don't work correctly Product: binutils Version: 2.18 Status: NEW Severity: critical Priority: P2 Component: gas AssignedTo: unassigned at sources dot redhat dot com ReportedBy: miro dot kropacek at gmail dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=6956 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
