0

I would like to inject a shared library into a process (I'm using ptrace() to do that part) and then be able to get output from the shared library back into the debugger I'm writing using some form of IPC. My instinct is to use a pipe, but the only real requirements are:

  • I don't want to store anything on the filesystem to facilitate the communication as it will only last as long as the debugger is running.
  • I want a portable Unix solution (so Unix-standard syscalls would be ideal).

The problem I'm running into is that as far as I can see, if I call pipe() in the debugger, there is no way to pass the "sending" end of the pipe to the target process, and vice versa with the receiving end. I could set up shared memory, but I think that would require creating a file somewhere so I could reference the memory segment from both processes. How do other debuggers capture output when they attach to a process after it has already begun running?

kumar_m_kiran
  • 3,982
  • 4
  • 47
  • 72
Dan
  • 7,155
  • 2
  • 29
  • 54
  • Any specific reason you have chosen unix pipes? Are both the code - debugger and the business logic in scripts? Or are they in any other language like Java/C++? – kumar_m_kiran Jun 24 '13 at 06:21
  • Both the injected library and the debugger are in C. I chose pipes because I've used them in similar situations (i.e. child process outputting to the shell that spawned it) but am open to other IPC types as well. – Dan Jun 24 '13 at 06:41

2 Answers2

0

I assume that you are in need of a debugging system for your business logic code (I mean application). From my experience, this kind of problem is tackled with below explained system design. (My experience is in C++, I think the same must hold good for the C based system also.)

  1. Have a logger system (a separate process). This will contain - logger manager and the logging code - which will take the responsibility of dumping the log into hard disk.
  2. Each application instance (process running in Unix) will communicate to this process with sockets. So you can have your own messaging protocol and communicate with the logger system with socket based communication.
  3. Later, for each of this application - have a switch which can switch off/on the log.So that you can have a tool - to send signal to this process to switch on/off the message logging.

At a high level, this is the most generic way to develop a logging system. In case you need any information - Do comment it. I will try to answer.

kumar_m_kiran
  • 3,982
  • 4
  • 47
  • 72
  • I think you misunderstood the question - I'm building a debugger and don't have access to the source of the target processes. I can still use a socket as you suggest for IPC, however it doesn't answer my question. Anyway, I found the solution I was looking for, which I've posted in an answer. – Dan Jun 24 '13 at 07:12
0

Using better search terms showed me this question is a dup of these guys:

The top answers were what I was looking for. You can use a Unix-domain socket to hand a file descriptor off to a different process. This could work either from debugger to library or vice versa, but is probably easier to do from debugger to library because the debugger can write the socket's address into the target process while it injects the library.

However, once I pass the socket's address into the target process, I might as well just use the socket itself instead of using a pipe in addition.

Community
  • 1
  • 1
Dan
  • 7,155
  • 2
  • 29
  • 54