Disassemble VxWorks (WindRiver) ELF Binaries?

[GeneralFailure]

Can anyone tell me or point me towards the documentation that explains how to disassemble a VxWorks (WindRiver) ELF binary?

I'm able to get an GNU objdump-esque memory map by clicking on binaries that have been built, but when I choose the disassembly option, I get a blank screen.

I do not want to interactively disassemble the binary on the target, but only check on the location of a specific (fatal) exception in application code.

[gvarndell]

Originally Posted by GeneralFailure

Can anyone tell me or point me towards the documentation that explains how to disassemble a VxWorks (WindRiver) ELF binary?

I'm able to get an GNU objdump-esque memory map by clicking on binaries that have been built, but when I choose the disassembly option, I get a blank screen.

I do not want to interactively disassemble the binary on the target, but only check on the location of a specific (fatal) exception in application code.

You have objdump -- it's called objdumpppc (yes, 3 p's).
Use a vxWorks development shell and it will be in your path.
Programs->Wind River->VxWorks 6.3 and General Purpose Technologies->VxWorks Development Shell.

[gvarndell]

There's a much easier way to disassemble -- if you're connected to the cRIO with Workbench debugger.
Use the Debug Symbol Browser.

[GeneralFailure]

Originally Posted by gvarndell

You have objdump -- it's called objdumpppc (yes, 3 p's).
Use a vxWorks development shell and it will be in your path.
Programs->Wind River->VxWorks 6.3 and General Purpose Technologies->VxWorks Development Shell.

Perfect, this is exactly what I needed to get the disassembly.

Any tips for the address space? The exception address doesn't match any of the addresses in the binary -- I assume they've been relocated.

I've got a Task address, but it doesn't seem to correspond to an address in the ELF binary either.

[GeneralFailure]

Originally Posted by gvarndell

There's a much easier way to disassemble -- if you're connected to the cRIO with Workbench debugger.
Use the Debug Symbol Browser.

This would be the preferred method I would use if the target still had the binary to be debugged on it. I'm trying to debug this off-line.

[gvarndell]

Originally Posted by GeneralFailure

Perfect, this is exactly what I needed to get the disassembly.

Any tips for the address space? The exception address doesn't match any of the addresses in the binary -- I assume they've been relocated.

I've got a Task address, but it doesn't seem to correspond to an address in the ELF binary either.

What is the exception? What is the address?
The exception address is where the PC was when the exception happened.
It's probably in one of the DKMs that get downloaded to the target.
This can be tricky because you can't easily 'predict' where the kernel will load DKMs.
However, you can 'see' where they actually got loaded by typing 'moduleShow' in the taget console.