Re: Possible bugs in gnu assembler for IA64
Hi Surbhi,
.section test
.quad 1f
.quad 2f
1:{
nop 0x0
nop 0x0
nop 0x0
}
2:{
nop 0x0
nop 0x0
nop 0x0
}
.previous
When I try to assemble this test using an ia64 assembler built from the
current mainline binutils sources I get two error messages:
% ia64-linux-as foo.s
foo.s:4: Warning: Directive invalid within a bundle
foo.s:9: Warning: Directive invalid within a bundle
Am I missing something from the command line ?
Cheers
Nick
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Possible bugs in gnu assembler for IA64
Hi Surbhi, Here is a easier pointer to the bug1: I am not an IA64 expert, but I took a look at this problem. .macro emul_ptr_i pr=p0,va,sz .section test, a, progbits (\pr) ptr.i \va,\sz .previous (\pr) ptr.i \va,\sz .endm nop.m 0x0 emul_ptr_i p1, r1, r2 Comment : both the ptr.i instructions go into the .text section. The first instruction is supposed to go in the test section. The problem it seems to me is that the test section is a data section and so the assembler does not want to put code into it. (Maybe the assembler should trust the program and put instructions there, but it certainly does not seem to want to). Anyway if I change the .section directive in your test case to: .section test, ax, progbits then the test works and the first ptr.i instruction is placed into the test section. Putting a .align(16) before the instruction insertion in the test section and after the .popsection, helps in putting the instructions in their respective sections. Are you sure ? This did not work when I tried it. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Possible bugs in gnu assembler for IA64
Hi, Here is a easier pointer to the bug1: $ as -v GNU assembler version 2.18.0 (ia64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 $ uname -a Linux lime 2.6.24-1-mckinley #1 SMP Sat Apr 19 00:19:28 UTC 2008 ia64 GNU/Linux About the bug: +++ I am attaching a small .S file. The objdump -D of its compiled version shows the error. .macro emul_ptr_i pr=p0,va,sz .section test, a, progbits (\pr) ptr.i \va,\sz .previous (\pr) ptr.i \va,\sz .endm nop.m 0x0 emul_ptr_i p1, r1, r2 Comment : both the ptr.i instructions go into the .text section. The first instruction is supposed to go in the test section. ___ Disassembly of section .text: .text: 0: 01 00 00 00 01 00 [MII] nop.m 0x0 6: 00 00 00 02 00 00 nop.i 0x0 c: 00 00 04 00 nop.i 0x0;; 10: 29 00 08 02 0d 44 [MMI] (p01) ptr.i r1,r2 16: 00 10 04 1a 08 00 (p01) ptr.i r1,r2 1c: 00 00 04 00 nop.i 0x0;; ___ Putting a .align(16) before the instruction insertion in the test section and after the .popsection, helps in putting the instructions in their respective sections. .macro emul_ptr_i pr=p0,va,sz .section test, a, progbits .align(16) (\pr) ptr.i \va,\sz .previous .align(16) (\pr) ptr.i \va,\sz .endm nop.m 0x0 emul_ptr_i p1, r1, r2 Hope this helps. Warm Regards, Surbhi. On Thu, 2008-10-16 at 19:10 +1100, Surbhi C wrote: Hi, I have attached a program with this email that can be used for proving the following cases which are some possible bugs in ia64-gnu-assembler: Here is what the tar.gz has 1) elf.h 2) elfOps.c 3) elfOps.h 4) fileIO.c 5) fileIO.h 6) initDb.ld 7) initialize.S 8) Makefile 9) origLdScript.ld 10) orig.S 11) replaceAnnotated.h 12) replaceOrigCode.c 13) README Here is some background on what the program does: make origElf creates a origElf file which has code to be replaced. 1) origElf has a section afterburn in it, which has annotation of some instructions. The annotation includes, a string that identifies the instruction, address of a instruction, length upto which replacement should be done, how many arguments the instruction has, and if it has arguments, then the original instruction. (The instructions which is annotated are really useles..and the code is arbitarily put in there.. the annotation is not entirely relevant here... however ..the only important information is the address in the annotation). 2) replaceOrigCode (created after make replaceOrigCode) similarly has a annotated section, which has the annotation of the corresponding replacement code. The annotation is again a string that identifies the original instruction to be replaced, the corresponding address, the length, and some information about the arguments. 3) The replaceOrigCode.c shall read the annotation in the afterburn section from the origElf file. It shall then replace the instructions which are annotated in the origElf with the corresponding instructions kept in its own elf image. However when a instruction has arguments, it reads the original instruction kept in the afterburn section of the origFile and puts it at the address mentioned, along with other code from the replacement code in the initialize.S. So basically, the aim is basically to replace some instructions or a block of code from origElf with some code kept in replaceOrigCode. While doing so, I encountered the following possible bugs in the ia64-gnu-assembler. The programs have a lot of printf statements which can be used to see that the contents of the annotated addresses changes with the way labelling is done and so on. Here is some more information: 1) Following is the output of as -v GNU assembler version 2.18.0 (ia64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 2) The output of uname -a is as follows: Linux torrone 2.6.15-1-mckinley-smp #2 SMP Mon Mar 6 17:47:45 UTC 2006 ia64 GNU/Linux Possible Bug 1: Here is a scenario : Case1) Contents of file named test ++ .macro emul_ptr_i pr=p0,va,sz .section afterburn, a, progbits .asciz ptr_i .quad 3f .quad 1 // length of the macro .quad 2 // num of args (\pr) ptr.i \va,\sz .previous [3:](\pr) ptr.i \va,\sz .endm mov r2=r1 emul_ptr_i p1, r1, r2 as test objdump -D a.out a.out: file format elf64-ia64-little Disassembly of section .text: .text: 0: 01 10 00 02 00 21 [MII] mov r2=r1 6: 00 00 00 02 00 00 nop.i 0x0 c: 00 00 04 00
Re: Possible bugs in gnu assembler for IA64
Hi, Here is a easier pointer to bug2: $ as -v GNU assembler version 2.18.0 (ia64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 $ uname -a Linux lime 2.6.24-1-mckinley #1 SMP Sat Apr 19 00:19:28 UTC 2008 ia64 GNU/Linux I have attached a file which contains the following: + lime:~/TEST$ cat bug.S .global main .proc main main:: .pushsection test, a, progbits .asciz 0 .quad 0 .quad 0 .align(16) (p0) itc.i r1 .popsection .align(16) .endp main lime:~/TEST$ as bug.S lime:~/TEST$ objdump -D a.out a.out: file format elf64-ia64-little Disassembly of section test: test: 0: 30 30 30 30 30 00 [MIB] (p01) srlz.d ... 1e: 00 00 0a 00 break.i 0x0 22: 04 00 2f 04 00 00 [MMI] itc.i r1;; 28: 00 02 00 00 00 00 nop.m 0x0 2e: 04 00 00 00 nop.i 0x0 Please note that itc.i r1;; starts at address 0x22, which is not 16 bytes aligned. +++ Hope this helps! Warm Regards, Surbhi. On Mon, 2008-10-20 at 10:47 +1100, Surbhi Chitre wrote: Hi, Here is a easier pointer to the bug1: $ as -v GNU assembler version 2.18.0 (ia64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 $ uname -a Linux lime 2.6.24-1-mckinley #1 SMP Sat Apr 19 00:19:28 UTC 2008 ia64 GNU/Linux About the bug: +++ I am attaching a small .S file. The objdump -D of its compiled version shows the error. .macro emul_ptr_i pr=p0,va,sz .section test, a, progbits (\pr) ptr.i \va,\sz .previous (\pr) ptr.i \va,\sz .endm nop.m 0x0 emul_ptr_i p1, r1, r2 Comment : both the ptr.i instructions go into the .text section. The first instruction is supposed to go in the test section. ___ Disassembly of section .text: .text: 0: 01 00 00 00 01 00 [MII] nop.m 0x0 6: 00 00 00 02 00 00 nop.i 0x0 c: 00 00 04 00 nop.i 0x0;; 10: 29 00 08 02 0d 44 [MMI] (p01) ptr.i r1,r2 16: 00 10 04 1a 08 00 (p01) ptr.i r1,r2 1c: 00 00 04 00 nop.i 0x0;; ___ Putting a .align(16) before the instruction insertion in the test section and after the .popsection, helps in putting the instructions in their respective sections. .macro emul_ptr_i pr=p0,va,sz .section test, a, progbits .align(16) (\pr) ptr.i \va,\sz .previous .align(16) (\pr) ptr.i \va,\sz .endm nop.m 0x0 emul_ptr_i p1, r1, r2 Hope this helps. Warm Regards, Surbhi. On Thu, 2008-10-16 at 19:10 +1100, Surbhi C wrote: Hi, I have attached a program with this email that can be used for proving the following cases which are some possible bugs in ia64-gnu-assembler: Here is what the tar.gz has 1) elf.h 2) elfOps.c 3) elfOps.h 4) fileIO.c 5) fileIO.h 6) initDb.ld 7) initialize.S 8) Makefile 9) origLdScript.ld 10) orig.S 11) replaceAnnotated.h 12) replaceOrigCode.c 13) README Here is some background on what the program does: make origElf creates a origElf file which has code to be replaced. 1) origElf has a section afterburn in it, which has annotation of some instructions. The annotation includes, a string that identifies the instruction, address of a instruction, length upto which replacement should be done, how many arguments the instruction has, and if it has arguments, then the original instruction. (The instructions which is annotated are really useles..and the code is arbitarily put in there.. the annotation is not entirely relevant here... however ..the only important information is the address in the annotation). 2) replaceOrigCode (created after make replaceOrigCode) similarly has a annotated section, which has the annotation of the corresponding replacement code. The annotation is again a string that identifies the original instruction to be replaced, the corresponding address, the length, and some information about the arguments. 3) The replaceOrigCode.c shall read the annotation in the afterburn section from the origElf file. It shall then replace the instructions which are annotated in the origElf with the corresponding instructions kept in its own elf image. However when a instruction has arguments, it reads the original instruction kept in the afterburn section of the origFile and puts it at the address mentioned, along with other code from the replacement code in the initialize.S. So basically, the aim is basically to replace some instructions or a block of code from origElf with some code kept in replaceOrigCode. While doing so
Re: Possible bugs in gnu assembler for IA64
nop.m 0x0
emul_ptr_i p1, r1, r2
Hope this helps.
Warm Regards,
Surbhi.
On Thu, 2008-10-16 at 19:10 +1100, Surbhi C wrote:
Hi,
I have attached a program with this email that can be used for proving
the following cases which are some possible bugs in ia64-gnu-assembler:
Here is what the tar.gz has
1) elf.h
2) elfOps.c
3) elfOps.h
4) fileIO.c
5) fileIO.h
6) initDb.ld
7) initialize.S
8) Makefile
9) origLdScript.ld
10) orig.S
11) replaceAnnotated.h
12) replaceOrigCode.c
13) README
Here is some background on what the program does:
make origElf creates a origElf file which has code to be replaced.
1) origElf has a section afterburn in it, which has annotation of
some instructions. The annotation includes, a string that identifies the
instruction, address of a instruction, length upto which replacement
should be done, how many arguments the instruction has, and if it has
arguments, then the original instruction. (The instructions which is
annotated are really useles..and the code is arbitarily put in there..
the annotation is not entirely relevant here... however ..the only
important information is the address in the annotation).
2) replaceOrigCode (created after make replaceOrigCode) similarly has a
annotated section, which has the annotation of the corresponding
replacement code. The annotation is again a string that identifies the
original instruction to be replaced, the corresponding address, the
length, and some information about the arguments.
3) The replaceOrigCode.c shall read the annotation in the afterburn
section from the origElf file. It shall then replace the instructions
which are annotated in the origElf with the corresponding instructions
kept in its own elf image. However when a instruction has arguments, it
reads the original instruction kept in the afterburn section of the
origFile and puts it at the address mentioned, along with other code
from the replacement code in the initialize.S.
So basically, the aim is basically to replace some instructions or a
block of code from origElf with some code kept in replaceOrigCode.
While doing so, I encountered the following possible bugs in the
ia64-gnu-assembler. The programs have a lot of printf statements which
can be used to see that the contents of the annotated addresses changes
with the way labelling is done and so on.
Here is some more information:
1) Following is the output of as -v
GNU assembler version 2.18.0 (ia64-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.18.0.20080103
2) The output of uname -a is as follows:
Linux torrone 2.6.15-1-mckinley-smp #2 SMP Mon Mar 6 17:47:45 UTC 2006
ia64 GNU/Linux
Possible Bug 1:
Here is a scenario :
Case1)
Contents of file named test
++
.macro emul_ptr_i pr=p0,va,sz
.section afterburn, a, progbits
.asciz ptr_i
.quad 3f
.quad 1 // length of the macro
.quad 2 // num of args
(\pr) ptr.i \va,\sz
.previous
[3:](\pr) ptr.i \va,\sz
.endm
mov r2=r1
emul_ptr_i p1, r1, r2
as test
objdump -D a.out
a.out: file format elf64-ia64-little
Disassembly of section .text:
.text:
0: 01 10 00 02 00 21 [MII] mov r2=r1
6: 00 00 00 02 00 00 nop.i 0x0
c: 00 00 04 00 nop.i 0x0;;
10: 29 00 08 02 0d 44 [MMI] (p01) ptr.i r1,r2
16: 00 10 04 1a 08 00 (p01) ptr.i r1,r2
1c: 00 00 04 00 nop.i 0x0;;
Disassembly of section afterburn:
afterburn:
0: 70 74 72 5f 69 00 [MIB] data8 0x34afb93a3
6: 00 00 00 00 00 00 break.i 0x0
c: 00 00 00 00 break.b 0x0
10: 01 00 00 00 00 00 [MII] break.m 0x0
16: 00 00 02 00 00 00 break.i 0x2000
1c: 00 00 00 00 break.i 0x0;;
Comments: Both the ptr.i are going in the .text section, even when we
have a .section directive which says that the first ptr.i should go in
to the afterburn section
Case 2:
Contents of file named test
++
.macro emul_ptr_i pr=p0,va,sz
.section afterburn, a, progbits
.asciz ptr_i
.quad 3f
.quad 1 // length of the macro
.quad 2 // num of args
(\pr) ptr.i \va,\sz
.previous
.previous
[3:](\pr) ptr.i \va,\sz
.endm
mov r2=r1
emul_ptr_i p1, r1, r2
Possible bugs in gnu assembler for IA64
Hi, I have attached a program with this email that can be used for proving the following cases which are some possible bugs in ia64-gnu-assembler: Here is what the tar.gz has 1) elf.h 2) elfOps.c 3) elfOps.h 4) fileIO.c 5) fileIO.h 6) initDb.ld 7) initialize.S 8) Makefile 9) origLdScript.ld 10) orig.S 11) replaceAnnotated.h 12) replaceOrigCode.c 13) README Here is some background on what the program does: make origElf creates a origElf file which has code to be replaced. 1) origElf has a section afterburn in it, which has annotation of some instructions. The annotation includes, a string that identifies the instruction, address of a instruction, length upto which replacement should be done, how many arguments the instruction has, and if it has arguments, then the original instruction. (The instructions which is annotated are really useles..and the code is arbitarily put in there.. the annotation is not entirely relevant here... however ..the only important information is the address in the annotation). 2) replaceOrigCode (created after make replaceOrigCode) similarly has a annotated section, which has the annotation of the corresponding replacement code. The annotation is again a string that identifies the original instruction to be replaced, the corresponding address, the length, and some information about the arguments. 3) The replaceOrigCode.c shall read the annotation in the afterburn section from the origElf file. It shall then replace the instructions which are annotated in the origElf with the corresponding instructions kept in its own elf image. However when a instruction has arguments, it reads the original instruction kept in the afterburn section of the origFile and puts it at the address mentioned, along with other code from the replacement code in the initialize.S. So basically, the aim is basically to replace some instructions or a block of code from origElf with some code kept in replaceOrigCode. While doing so, I encountered the following possible bugs in the ia64-gnu-assembler. The programs have a lot of printf statements which can be used to see that the contents of the annotated addresses changes with the way labelling is done and so on. Here is some more information: 1) Following is the output of as -v GNU assembler version 2.18.0 (ia64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 2) The output of uname -a is as follows: Linux torrone 2.6.15-1-mckinley-smp #2 SMP Mon Mar 6 17:47:45 UTC 2006 ia64 GNU/Linux Possible Bug 1: Here is a scenario : Case1) Contents of file named test ++ .macro emul_ptr_i pr=p0,va,sz .section afterburn, a, progbits .asciz ptr_i .quad 3f .quad 1 // length of the macro .quad 2 // num of args (\pr) ptr.i \va,\sz .previous [3:](\pr) ptr.i \va,\sz .endm mov r2=r1 emul_ptr_i p1, r1, r2 as test objdump -D a.out a.out: file format elf64-ia64-little Disassembly of section .text: .text: 0: 01 10 00 02 00 21 [MII] mov r2=r1 6: 00 00 00 02 00 00 nop.i 0x0 c: 00 00 04 00 nop.i 0x0;; 10: 29 00 08 02 0d 44 [MMI] (p01) ptr.i r1,r2 16: 00 10 04 1a 08 00 (p01) ptr.i r1,r2 1c: 00 00 04 00 nop.i 0x0;; Disassembly of section afterburn: afterburn: 0: 70 74 72 5f 69 00 [MIB] data8 0x34afb93a3 6: 00 00 00 00 00 00 break.i 0x0 c: 00 00 00 00 break.b 0x0 10: 01 00 00 00 00 00 [MII] break.m 0x0 16: 00 00 02 00 00 00 break.i 0x2000 1c: 00 00 00 00 break.i 0x0;; Comments: Both the ptr.i are going in the .text section, even when we have a .section directive which says that the first ptr.i should go in to the afterburn section Case 2: Contents of file named test ++ .macro emul_ptr_i pr=p0,va,sz .section afterburn, a, progbits .asciz ptr_i .quad 3f .quad 1 // length of the macro .quad 2 // num of args (\pr) ptr.i \va,\sz .previous .previous [3:](\pr) ptr.i \va,\sz .endm mov r2=r1 emul_ptr_i p1, r1, r2 as test objdump -D a.out a.out: file format elf64-ia64-little Disassembly of section .text: .text: 0: 01 10 00 02 00 21 [MII] mov r2=r1 6: 00 00 00 02 00 00 nop.i 0x0 c: 00 00 04 00 nop.i 0x0;; Disassembly of section afterburn: afterburn: 0: 70 74 72 5f 69 00 [MIB] data8 0x34afb93a3 6: 00 00 00 00 00 00 break.i 0x0 c: 00 00 00 00 break.b 0x0 10: 01 00 00 00 00
