This content has been marked as final. Show 7 replies
863128 wrote:In theory yes, but dbxtool doesn't support this scenario.
Is it possible to make dbxtool open the files from the local host
dbxtool expects that sources are uniformly available via some network file system (NFS).
In remote mode dbxtool starts the src level debugger, 'dbx', on the
prod machine. Because 'dbx' can't find the sources it switches to disassembly mode
and drives the GUI that way.
The IDE (Studio) supports a copying mode but then if you want to keep your source
code secure you probably don't want it to be quietly copied by the IDE into some cache
Right, that's about what I thought.
I was tempted to do some sort of here/expect document / parse the output from dbx, and just catch the error, and launch the editor somehow. If SolStudio is using a text based protocol to dbx over ssh, say, then a wrapper might do it, but if it's a real protocol, that'd be, err, tougher :)
Some of the docs on DDD I saw suggested it might be possible, but actual support for dbx seemed thin. I think I could do it with gdb, but am assuming I can't debug a sunstudio binary with gdb..?
The protocol between dbx and dbxtool/IDE is binary.
A textual protocol, like gdb's MI, usurps the actual user cmdline channel
which is why with gdb you get either a gdb cmdline or GUI interaction
and the cmdline interaction (i.e. history, completion) suffers.
Debugging code compiled with Sun/Oracle compilers with gdb won't
work very well.
If you have a support contract you could ask for an enhancement fix
where dbx doesn't switch to assembly mode if it doesn't find the actual source file,
but I dunno what other things might not work. I do know things work in the other
direction. That is, if you open a source file in dbxtool on the dev machine
and place a breakpoint it will take. Note that the required fix would be
in dbx not the GUI's
One, admittedly horrid, hack that comes to mind is to fool dbx on the prod machine
with empty source files so it thinks they are there and doesn't switch to assembly
863128 wrote:I understand. That won't work. dbx will look for a specific file name as encoded into the debuginfo
Sorry, I just meant use generic names for the files, like WorkerA.cpp instead of SecretSauceFlavourABC.cpp
in the a.out by the compiler.
In as sense if you have a non-stripped a.out in the wild you've already revealed your source filenames.
These filenames appear even if you don't use -g. Apply a "strings" to your binary to get a feel for
what sort of stuff is encoded in it.