Since shellcode is just a raw block of instructions, these tools aren't really suited.
Wat? Executables are just raw blocks of instructions too! No really. Ok, maybe there's bits of data in there for PE/ELF headers or the like, or just plain program data, but the data is the same binary as instructions. To the point sections of executables are labelled (text, data) so the OS knows what to treat as what.
For a demo, take any set of assembler and type:
nasm -f bin <asmfile.asm>
That'll do absolutely no additional work bar translating the assembler instructions to opcodes and writing it down in a binary file. This is how you'd go about writing a bootloader or the like.
Now, if you wanted to analyse some shellcode, there's a multitude of ways you could do it. For starters, you could just use a harness:
#include <stdio.h>
char shellcode[] = { ... };
int main()
{
int (*function)() = shellcode;
function();
}
and voila you're off - simply get gdb or the like to single step through it. Of course, if you wanted to analyse that particularl piece of shell code statically, well, there's a way for that too:
#include <stdio.h>
char shellcode[] = { ... };
int main()
{
FILE* f = fopen('test.bin', 'wb');
fwrite(shellcode, sizeof(shellcode), f);
fclose(f);
}
and now you have a binary blob to work with. Actually, chances are you had to do the inverse of this to load the code into the test harness (i.e. escape it) anyway.
If you're looking for tools, I suggest the x86 wikibook. Basically, it comes down to picking one or more you can afford and having a play.
Unless the shellcode contains anti-debugging measures (remember, it's space-constrained) chances are a runtime debugger with the test harness will work just fine.