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:
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:
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.
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.
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.
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 )
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.
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.
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 ;-)
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
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.