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
Re: Possible bugs in gnu assembler for IA64
Hi,
Here is a pointer to the last bug mentioned in the first email..
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 explains the bug.
The bug is as follows: The label of a bundle does not work properly,
when the bundle is not in .text section
For eg :
.section test
.quad 1f
.quad 2f
1:{
nop 0x0
nop 0x0
nop 0x0
}
2:{
nop 0x0
nop 0x0
nop 0x0
}
.previous
Comment:
2: refers to the address of the first bundle rather than the second.
This happens when the bundles are in a section other than the text
section. This can be confirmed by the objdump -D of the executable
of this file. One can verify the contents of test section corresponding
to .quad 1f and .quad 2f - both of them seem to be the same,
when actually they should some addr and some addr + 16
Please refer to the file bug3.S
$ gcc bug3.S
$ objdump -D a.out
Disassembly of section test1:
4780 test1:
4780: a0 07 00 00 00 00 [MII] (p61) break.m 0x0
4786: 00 40 a0 07 00 00 data8 0x01e81
478c: 00 00 00 40dep r0=r0,r0,63,1
4790: b0 07 00 00 00 00 [MIB] (p61) break.m 0x0
4796: 00 40 c0 07 00 00data8 0x01f01
479c: 00 00 00 40 br.few 4790 _fini+0x30
47a0: 10 00 00 00 01 00 [MIB] nop.m 0x0
47a6: 00 00 00 02 00 00 nop.i 0x0
47ac: 00 00 40 00 epc
Please refer to the contents at the locations 4780:
They are : a0 07 00 00 00 00 00 40 and a0 07 00 00 00 00 00 40
which is the starting address of the bundle containing epc.
Actually the contents should have been
a0 07 00 00 00 00 00 40
b0 07 00 00 00 00 00 40
Hope this helps.
Thanks !
Warm Regards,
Surbhi.
On Mon, 2008-10-20 at 11:50 +1100, Surbhi Chitre wrote:
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
