| View previous topic :: View next topic |
| Author |
Message |
mharris
Joined: 25 Jan 2004
Posts: 155
Location: Annapolis, MD, USA
|
 Posted: Tue Jan 11, 2005 9:02 am Post subject: dvp-objdump disassembly |
 |
|
The version of dvp-objdump that I have (built w/ Oopo's toolchain.sh, on Linux) does not seem to be capable of disassembling VU code correctly. It looks like it's always doing MIPS disassembly, regardless of the -m dvp:vu or other settings. I found a hook in the
binutils-2.14/opcodes/mips-dis.c module that checks to see if ARCH_dvp is defined, but the makefile only defines that for binutils-2.14/opcodes/disassemble.c
Rather than mess around w/ the hideous automake-generated makefiles to pass this flag on to mips-dis.c, I patched opcodes/disassemble.c directly. As a result, the dvp-objdump version will allow disassembly of vu code and vif/gif/dma packets, but will no longer disasm mips code (we have ee-objdump and iop-objdump for this anyhow).
The patch is ridiculously short, and seems to work for me: | Code: | --- orig.binutils-2.14/opcodes/disassemble.c 2005-01-10 15:55:12.000000000 -0500
+++ binutils-2.14/opcodes/disassemble.c 2005-01-10 15:42:30.000000000 -0500
@@ -237,10 +237,14 @@
#endif
#ifdef ARCH_mips
case bfd_arch_mips:
+#ifdef ARCH_dvp
+ disassemble = print_insn_dvp;
+#else /* !ARCH_dvp */
if (bfd_big_endian (abfd))
disassemble = print_insn_big_mips;
else
disassemble = print_insn_little_mips;
+#endif /* ARCH_dvp */
break;
#endif
#ifdef ARCH_mmix |
Apply this patch after the other binutils patch. |
|
| Back to top |
|
 |
mharris
Joined: 25 Jan 2004
Posts: 155
Location: Annapolis, MD, USA
|
| Posted: Tue Mar 08, 2005 10:23 am Post subject: |
|
|
Hmm, looks like my patch may have broken EE disassembly via ee-objdump. It seems that ARCH_dvp is defined for the EE binutils configuration, and so any attempt to use the disassembler in ee-objdump treats the object file as a DVP object (VU, etc.), and won't show the R5900 opcodes as expected.
In the generated file build-ee/opcodes/Makefile (using ps2toolchain/toochain.sh), there are several references to the dvp, which I don't think should be there. This particular Makefile (the one in the opcodes dir) is the only one where it's present. A grep for 'dvp' in this file reveals: | Code: | opcodes/Makefile:BFD_MACHINES = mips-dis.lo mips-opc.lo mips16-opc.lo dvp-dis.lo dvp-opc.lo
opcodes/Makefile:archdefs = -DARCH_mips -DARCH_dvp
opcodes/Makefile:OFILES = mips-dis.lo mips-opc.lo mips16-opc.lo dvp-dis.lo dvp-opc.lo
opcodes/Makefile: $(LIBTOOL) --mode=compile $(COMPILE) -c -DARCH_mips -DARCH_dvp $(srcdir)/disassemble.c
opcodes/Makefile: $(LIBTOOL) --mode=compile $(COMPILE) -c -DARCH_mips -DARCH_dvp $< |
I'll dig around some more and see if I can find out why this is happening. |
|
| Back to top |
|
|
mharris
Joined: 25 Jan 2004
Posts: 155
Location: Annapolis, MD, USA
|
| Posted: Tue Mar 08, 2005 3:32 pm Post subject: |
|
|
I am thinking that the cause of the error is the following lines in bfd/config.bfd (in the binutils project):
| Code: | case "${targ}" in
mips64*-scei*-elf*) targ_archs="${targ_archs} bfd_dvp_arch" ;;
esac |
It looks like whenever building for the mips64r5900el-scei-elf target, we automatically get dvp added as an additional target. These lines have been in the binutils patch for as far back as I can tell, so maybe it's been there all along (and my earlier 'fix' to the disassembly code just exposed it).
For anyone with more history on the toolchain than I have: can you think of a reason why the DVP stuff would have been added to the EE toolchain? Were these combined at one point (i.e., there were no separate dvp-* tools)?
I'm too tired right now to do a full regression test (which I should have done when I suggested the earlier patch back in January), so it'll have to wait until tomorrow before I can say whether or not this is the problem. |
|
| Back to top |
|
|
pixel
Joined: 30 Jan 2004
Posts: 791
|
| Posted: Tue Mar 08, 2005 4:02 pm Post subject: |
|
|
Ah, huh, yeah, of course: you can build vu0 code for EE, since one of its behavior is to act as the ee's cop2. So, you need to have some of the dvp instruction support for EE. I think.... Huh.... doesn't sound right to me. I'll look at it whenever I found some spare minutes to do so :P
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department. |
|
| Back to top |
|
|
mharris
Joined: 25 Jan 2004
Posts: 155
Location: Annapolis, MD, USA
|
| Posted: Tue Mar 08, 2005 11:03 pm Post subject: |
|
|
| pixel wrote: | | Ah, huh, yeah, of course: you can build vu0 code for EE, since one of its behavior is to act as the ee's cop2. So, you need to have some of the dvp instruction support for EE. I think.... Huh.... doesn't sound right to me. I'll look at it whenever I found some spare minutes to do so :P |
Mumble. Oh yeah, the COP2 instructions... right. OK, that idea won't work, gotta think of something else, I guess. |
|
| Back to top |
|
|
mharris
Joined: 25 Jan 2004
Posts: 155
Location: Annapolis, MD, USA
|
| Posted: Wed Mar 09, 2005 5:41 am Post subject: |
|
|
OK, think I've got it fixed now. Two simple changes to disassemble.c
Like I said, I'm gonna do as full a regression test as I can to make sure nothing's broken before releasing -- this includes building EE C source with inline COP2 VU instructions, micro-mode VU asm, and (just to be safe) some IOP stuff. I'll verify by using the corresponding disassemblies via objdump -d.
(Really, the only component that should be affected is the disassembly, but having been burned once, I don't want to release another buggy patch. Our QA department must have been asleep at the switch ;-P ) |
|
| Back to top |
|
|
J.F.
Joined: 22 Feb 2004
Posts: 2906
|
| Posted: Wed Mar 09, 2005 5:48 am Post subject: |
|
|
| I'm certainly not QA. I usually wait for all the reports of problems to clear up, then run the latest toolchain script. :) |
|
| Back to top |
|
|
MrHTFord
Joined: 10 Feb 2004
Posts: 35
Location: England
|
| Posted: Wed Mar 09, 2005 10:42 pm Post subject: |
|
|
| I'll do some QA if you post the patch. |
|
| Back to top |
|
|
mharris
Joined: 25 Jan 2004
Posts: 155
Location: Annapolis, MD, USA
|
| Posted: Fri Mar 11, 2005 2:59 pm Post subject: |
|
|
OK, finally I've gotten all three objdumps (ee, iop, dvp) to do what they're supposed to do. Here's the patch to binutils-2.14.patch.
If someone wants to give me cvs commit rights, I can pop it in myself.
| Code: | diff -u ps2toolchain/binutils-2.14.patch ps2toolchain.mharris/binutils-2.14.patch
--- ps2toolchain/binutils-2.14.patch Wed Jan 19 23:59:53 2005
+++ ps2toolchain.mharris/binutils-2.14.patch Fri Mar 11 04:35:00 2005
@@ -7099,28 +7099,21 @@
diff -uNr binutils-2.14/opcodes/disassemble.c ps2-binutils-2.14/opcodes/disassemble.c
--- binutils-2.14/opcodes/disassemble.c Tue Apr 1 17:50:30 2003
+++ ps2-binutils-2.14/opcodes/disassemble.c Thu Jan 20 00:59:49 2005
-@@ -75,6 +75,9 @@
- #define INCLUDE_SHMEDIA
+@@ -232,12 +232,16 @@
+ disassemble = print_insn_mcore;
+ break;
#endif
-
-+#if defined (ARCH_dvp) && ! defined (ARCH_mips)
-+#define ARCH_mips
-+#endif
-
- disassembler_ftype
- disassembler (abfd)
-@@ -234,10 +237,14 @@
- #endif
- #ifdef ARCH_mips
+-#ifdef ARCH_mips
++#if defined(ARCH_mips) || defined(ARCH_dvp)
case bfd_arch_mips:
-+#ifdef ARCH_dvp
-+ disassemble = print_insn_dvp;
-+#else /* !ARCH_dvp */
++#ifdef ARCH_mips
if (bfd_big_endian (abfd))
disassemble = print_insn_big_mips;
else
disassemble = print_insn_little_mips;
-+#endif /* ARCH_dvp */
++#else
++ disassemble = print_insn_dvp;
++#endif
break;
#endif
#ifdef ARCH_mmix
|
Beware: the tabs may have gotten munged up when I posted it here, so you may have to finagle with the two lines that have tabs in them (the lines with 'disassemble = print_insn_xxx_mips;'); they must begin with space, space, tab or patch may get confused. |
|
| Back to top |
|
|
pixel
Joined: 30 Jan 2004
Posts: 791
|
| Posted: Fri Mar 11, 2005 7:53 pm Post subject: |
|
|
Done. Please check I didn't break your patch :)
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department. |
|
| Back to top |
|
|
cory1492
Joined: 10 Dec 2004
Posts: 216
|
| Posted: Sat Mar 12, 2005 1:31 am Post subject: |
|
|
Here is the result I get (twice) trying to reinstall the toolchain with the new patches using ooPo's script:
| Code: | /bin/sh ./libtool --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototy
pes -g -O2 -o cxxfilt.exe cxxfilt.o bucomm.o version.o filemode.o ../bfd/libbf
d.la ../libiberty/libiberty.a ./../intl/libintl.a
gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -g -O2 -o cxxfilt.exe cxxf
ilt.o bucomm.o version.o filemode.o ../bfd/.libs/libbfd.a ../libiberty/libibert
y.a ./../intl/libintl.a
make[3]: Leaving directory `/tmp/ps2dev/binutils-2.14/build-ee/binutils'
make[2]: Leaving directory `/tmp/ps2dev/binutils-2.14/build-ee/binutils'
make[1]: Leaving directory `/tmp/ps2dev/binutils-2.14/build-ee/binutils'
Configuring in gas
loading cache .././config.cache
checking for Cygwin environment... (cached) yes
checking for mingw32 environment... (cached) no
checking host system type... i686-pc-cygwin
checking target system type... mips64r5900el-scei-elf
checking build system type... i686-pc-cygwin
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -g -O2 ) works... yes
checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for POSIXized ISC... no
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... missing
checking for working autoconf... missing
checking for working automake... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking for ld used by GCC... (cached) /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/..
/../../../i686-pc-cygwin/bin/ld.exe
checking if the linker (/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-p
c-cygwin/bin/ld.exe) is GNU ld... (cached) yes
checking for /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i686-pc-cygwin/bi
n/ld.exe option to reload object files... (cached) -r
checking for BSD-compatible nm... (cached) nm
checking whether ln -s works... (cached) yes
checking how to recognise dependant libraries... (cached) file_magic file format
pei*-i386(.*architecture: i386)?
checking for object suffix... (cached) o
checking for executable suffix... (cached) .exe
checking for ranlib... (cached) ranlib
checking for strip... (cached) strip
updating cache .././config.cache
loading cache .././config.cache within ltconfig
checking for objdir... .libs
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... (cached) yes
checking if gcc static flag -static works... (cached) yes
finding the maximum length of command line arguments... (cached) 12289
checking if gcc supports -c -o file.o... (cached) yes
checking if gcc supports -fno-rtti -fno-exceptions ... no
checking whether the linker (/usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/../../../../i
686-pc-cygwin/bin/ld.exe) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
checking command to parse nm output... ok
checking if libtool supports shared libraries... yes
checking if package supports dlls... no
checking whether to build shared libraries... no
checking whether to build static libraries... yes
eval: Cannot fork: Permission denied
eval: Cannot fork: Permission denied
eval: Cannot fork: Permission denied
eval: Cannot fork: Permission denied
eval: Cannot fork: Permission denied
creating libtool
../../gas/../ltconfig: rm: permission denied
../../gas/../ltconfig: Cannot fork: Permission denied
../../gas/../ltconfig: Cannot fork: Permission denied
../../gas/../ltconfig: Cannot fork: Permission denied
../../gas/../ltconfig: sed: permission denied
../../gas/../ltconfig: Cannot fork: Permission denied
../../gas/../ltconfig: chmod: permission denied
../../gas/../ltconfig: cat: permission denied
../../gas/../ltconfig: Cannot fork: Permission denied
configure: error: libtool configure failed
make: *** [configure-gas] Error 1
ERROR BUILDING BINUTILS (binutils-2.14 ee) |
broken?? or just me? |
|
| Back to top |
|
|
mharris
Joined: 25 Jan 2004
Posts: 155
Location: Annapolis, MD, USA
|
| Posted: Sat Mar 12, 2005 1:59 am Post subject: |
|
|
| Quote: | checking whether to build static libraries... yes
eval: Cannot fork: Permission denied
eval: Cannot fork: Permission denied
eval: Cannot fork: Permission denied
eval: Cannot fork: Permission denied
eval: Cannot fork: Permission denied |
I think it's just you, mate... I can't figure out why a fork() syscall would return EPERM, it's not supposed to.
It looks like you're building under cygwin -- are there any oddball permissions on directories that got messed up? Of course, you're running under windows, reboot and try again ;-) |
|
| Back to top |
|
|
cory1492
Joined: 10 Dec 2004
Posts: 216
|
| Posted: Sat Mar 12, 2005 2:41 am Post subject: |
|
|
the second time was after a reboot. I am reinstalling cygwin ATM to be sure perms werent messed about...
edit: did the reinstall, same error as before, will muck about with this more tomorrow and see if it still builds using the "broken" patches...
here is all I could find on this:
http://lists.blitzed.org/pipermail/bopm/2002-December/000648.html
Im thinking my local install of cygwin is corrupted or something similar...
one last edit:
ok, after mucking about for a long time on this, I reinstalled cygwin (makes it the 3rd time in the last 24hrs), downloaded ps2toolchain-20050307.tgz from ooPos site and that built fine from start to finish. With the newest stuff from CVS it gets to the end of the first ./configure and starts spouting off about forks and permissions (on a clean install). I will attempt to narrow the problem by comaring the older files from the tgz to what is there now, but I have no idea what Im looking for so that will likely be a waste on my part.
ah well, I was looking for an excuse to build the toolchain under Xebian on the xbox anyways |
|
| Back to top |
|
|
cory1492
Joined: 10 Dec 2004
Posts: 216
|
| Posted: Sun Mar 13, 2005 7:08 pm Post subject: |
|
|
after much head scratching and looking around at whatchamacallits, I wound up doing the download, extract and patch from oopos script, then restarted the pc and ran the script modded so it no longer looked to extract or create any files, just diving right into the compiling and so far so good, no fork problems (not on xebian, on cygwin). my fingers are crossed, ee-objdump would be handy indeed.
spoke too soon, it forked up when it tried to configure sed in gas... guess Ill just have to be patient and wait for lukasz to update his build for cygwin. |
|
| Back to top |
|
|
cory1492
Joined: 10 Dec 2004
Posts: 216
|
| Posted: Wed Mar 16, 2005 11:32 pm Post subject: |
|
|
Ok, just built a virtual vmware Gentoo machine for doing the compiling - it actually works much faster than cygwin and has all of linux going for it.
The entire toolchain built flawlessly in less than 1/2 the time it take to go on cygwin. shift-delete-cygwin. thats all I can say ;) |
|
| Back to top |
|
|
ooPo
Site Admin
Joined: 17 Jan 2004
Posts: 2032
Location: Canada
|
| Posted: Thu Mar 17, 2005 1:34 am Post subject: |
|
|
| I don't think anyone ever uses cygwin because they choose to. :) |
|
| Back to top |
|
|
MrHTFord
Joined: 10 Feb 2004
Posts: 35
Location: England
|
| Posted: Fri Mar 18, 2005 6:25 am Post subject: |
|
|
You could also have used my mingw patchset available on oopo's site...
...if I'd mentioned it to anyone, that is.
MrHTFord. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
