Они - то же самое . URI является обобщением URL. Первоначально, URIs были запланированы, чтобы быть разделенными на URL (адреса) и УРНЫ (имена), но тогда было мало различия между URL и URI, и http URIs использовались в качестве пространств имен даже при том, что они на самом деле не определяли местоположение никаких ресурсов.
Если это Linux (как предполагают теги), вы можете поделиться всем адресным пространством дочернего элемента с родительским, используя clone ()
с Флаг CLONE_VM
. Поскольку два процесса используют одно и то же пространство виртуальной машины, все изменения будут немедленно видны между ними, практически без накладных расходов.
Это означает, что вы не можете затем exec ()
в дочернем элементе; поскольку он заменит пространство виртуальных машин обоих процессов.
Контролируете ли вы дочерний процесс и его исходный код? Если это так, вы можете рассмотреть возможность использования общей памяти .
Если вы контролируете дочерний процесс, может быть, вы могли бы добавить интерфейс отладки, позволяющий записывать данные в рассматриваемую память?
Рассмотрите возможность внедрения некоторой функции отладки в процесс ptrace и ее вызова через ptrace_setregs. Что-то вроде того, как gdb может запускать любую функцию процесса ptraced.
Также вы можете попробовать внедрить код в процесс через LD_PRELOAD. Можно даже попробовать заставить работать без ptrace, используя сигналы.
upd1: Внедрение Gdb или «вызов подчиненной функции» довольно сложен. См. Функцию call_function_by_hand в файле gdb-6.6.50.20070809 ›gdb› infcall.c здесь: http://sources.debian.net/src/gdb/7.6.2-1/gdb/infcall.c?hl=462 # L462
/* All this stuff with a dummy frame may seem unnecessarily complicated
(why not just save registers in GDB?). The purpose of pushing a dummy
frame which looks just like a real frame is so that if you call a
function and then hit a breakpoint (get a signal, etc), "backtrace"
will look right. Whether the backtrace needs to actually show the
stack at the time the inferior function was called is debatable, but
it certainly needs to not display garbage. So if you are contemplating
making dummy frames be different from normal frames, consider that. */
/* Perform a function call in the inferior.
ARGS is a vector of values of arguments (NARGS of them).
FUNCTION is a value, the function to be called.
Returns a value representing what the function returned.
May fail to return, if a breakpoint or signal is hit
during the execution of the function.
ARGS is modified to contain coerced values. */
struct value *
call_function_by_hand (struct value *function, int nargs, struct value **args)
{
...
frame = get_current_frame ();
gdbarch = get_frame_arch (frame);
if (!gdbarch_push_dummy_call_p (gdbarch))
error (_("This target does not support function calls."));
/* A cleanup for the inferior status.
This is only needed while we're preparing the inferior function call. */
inf_status = save_infcall_control_state ();
inf_status_cleanup
= make_cleanup_restore_infcall_control_state (inf_status);
/* Save the caller's registers and other state associated with the
inferior itself so that they can be restored once the
callee returns. To allow nested calls the registers are (further
down) pushed onto a dummy frame stack. Include a cleanup (which
is tossed once the regcache has been pushed). */
caller_state = save_infcall_suspend_state ();
make_cleanup_restore_infcall_suspend_state (caller_state);
...
sp = push_dummy_code (gdbarch, sp, funaddr, args, nargs,
target_values_type, &real_pc, &bp_addr,
get_current_regcache ());
... pass args ...
/* Create the dummy stack frame. Pass in the call dummy address as,
presumably, the ABI code knows where, in the call dummy, the
return address should be pointed. */
sp = gdbarch_push_dummy_call (gdbarch, function, get_current_regcache (),
bp_addr, nargs, args,
sp, struct_return, struct_addr);
...
/* Everything's ready, push all the info needed to restore the
caller (and identify the dummy-frame) onto the dummy-frame
stack. */
dummy_frame_push (caller_state, &dummy_id);
...
/* Run the inferior until it stops. */
e = run_inferior_call (tp, real_pc);
}
Для чтения лучше всего разобрать файл /proc/
на предмет виртуальных адресов интересующих областей памяти.
Затем вы можете прочитать их, открыв /proc/
и выполнив read()
вызов с большим буфером на интересующих областях.
Для записи я еще не нашел простого способа записывать целые блоки, я полагаю, что это связано с блокировкой и стабильностью дочернего процесса, вызовы через ptrace()
могут гарантировать это, но прямой доступ к памяти другого процесса не может. Обычно я пишу обертку вокруг ptrace(PTRACE_POKEDATA, ...)
для зеркального отражения WriteProcessMemory()
Windows.
clone или mmap - это то, что вы ищете. mmap временный файл между двумя процессами и использование этого пространства памяти для передачи данных туда и обратно.