This discussion is archived
7 Replies Latest reply: May 21, 2013 2:13 PM by IvanIgorovich RSS

Remote DBX with local source in dbxtool / sol studio

866131 Newbie
Currently Being Moderated
Hi,

I'm trying to debug a process on a remote host (prod machine, say) from a machine containing the source/objects (dev machine). When the dbx stops at a breakpoint and tried to load the source, however, it seems to be the remote dbx which tries to open the files, which are only located (for security reasons) on the dev host. Is it possible to make dbxtool open the files from the local host (ie the one the GUI is running on)? (Solaris 10 running on dev and prod).

I've also tried solaris studio, which does show the disassembled code but doesn't link to the src in the project.

Any idea if this is possible?

Thanks,

Ken.
  • 1. Re: Remote DBX with local source in dbxtool / sol studio
    IvanIgorovich Newbie
    Currently Being Moderated
    863128 wrote:
    Hi,

    Is it possible to make dbxtool open the files from the local host
    In theory yes, but dbxtool doesn't support this scenario.
    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
    area either.
  • 2. Re: Remote DBX with local source in dbxtool / sol studio
    866131 Newbie
    Currently Being Moderated
    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..?
  • 3. Re: Remote DBX with local source in dbxtool / sol studio
    IvanIgorovich Newbie
    Currently Being Moderated
    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
    mode.
  • 4. Re: Remote DBX with local source in dbxtool / sol studio
    866131 Newbie
    Currently Being Moderated
    Thanks for the ideas. I guess the empty src files is worth a try, though then there's a temptation to obfuscate the file names, which feels even hackier / more painful.
  • 5. Re: Remote DBX with local source in dbxtool / sol studio
    IvanIgorovich Newbie
    Currently Being Moderated
    If you obfuscate the filenames then dbx won't find them and switch to
    assembly mode.
  • 6. Re: Remote DBX with local source in dbxtool / sol studio
    866131 Newbie
    Currently Being Moderated
    Sorry, I just meant use generic names for the files, like WorkerA.cpp instead of SecretSauceFlavourABC.cpp
  • 7. Re: Remote DBX with local source in dbxtool / sol studio
    IvanIgorovich Newbie
    Currently Being Moderated
    863128 wrote:
    Sorry, I just meant use generic names for the files, like WorkerA.cpp instead of SecretSauceFlavourABC.cpp
    I understand. That won't work. dbx will look for a specific file name as encoded into the debuginfo
    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.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points