I am trying to compile a program which, when run, will be run in a predefined environment in c.
More specifically, I am looking to somehow include LD_PRELOAD=./lib.so so that when I run ./program it will run as if I had used the command LD_PRELOAD=./lib.so ./program
Does anyone know if this is possible?
Make the program set LS_PRELOAD and then run itself if LS_PRELOAD isn't set. Use execv() for that.
Related
I always use the -x (or debug flag) when it come to bash script, or shell scripts in general.
Now i'm curious to know, is there an equivalent, either using a specific compiler options, (i use gcc, but i don't mind any other compilers) or by using a specific code in my project?
Basically i just wanted a way to emulate what bash does (using the debug flag) which show which command/function was launched first, in order, and also show the output of said function, with additional errors message etc.But for C.
I'm aware of most debug option out there, especially considering the compiler, but i really wish i could do this in my C projects too.(especially the part where it show what is executed in order, like bash does with -x)
NB: There isn't any goal in this specific question beside the question itself, as i'm just curious if this exist, and thus don't have any need for it beside the actual knowledge acquired from said answered question.
Yes, you can mimic this behaviour with a debugger.
With GDB for instance you can write "Init Files" and "Command Files" in which you can write a simple loop:
break main
run
while 1
next
end
If you put a file named .gdbinit in the directory where you start gdb, this file will be executed or gdb will lead you on the way to configure it in order that it will be executed.
The other option is to pipe this file into your gdb-call:
gdb a.out < debug_me_like-x
Where the "debug_me_like-x" file is the one mentioned above.
As a reference for the "Command Files" have a look here.
What is the best way to compile programs inside emacs? I am currently opening a separate buffer with C-x 3 and running eshell inside it using M-x eshell then invoking either make or clang directly; most of the time I do have a Makefile set up.
Is there any advantage with running the compilation process using M-x compile vs running make inside eshell? Any other ways to do it and what are the advantages/disadvantages of those?
The easiest way to do this is to use the Emacs built-in compile command. M-x compile should do you fine. You can then edit the command that will be run (by default make -k) and then hit return to run the compilation. Emacs will then parse the output and if it finds any errors they will link to the source files so you can open them in a buffer.
Positives about it are:
Parsing of the output buffer
Memorisation of the compile command between invocations
Compilation output is shown in a non-selected buffer, you can quickly edit the file you were working on and fix any silly errors.
M-n and M-p scroll by error messages
Most of these features are provided by the compilation-minor-mode minor mode though not the actual compilation command and buffer. Once you have run a compilation command in eshell you could probably get similar results by setting the minor mode to compilation-minor-mode.
I personally prefer to run make or whatever command you're using to
compile within a multi-term
for the following reasons:
it works like M-xcompileRET if you activate
compilation-shell-minor-mode (M-p, C-`, …).
but you can, obviously, use other commands like
mkdir build
cd build
./configure --with-another-option
Of course you can do this from Emacs but I prefer the shell
interaction for this kind of stuff.
And imo, the main drawback of M-xcompile is that if
you're editing a file located in another directory than your
Makefile then you have to use M-xcompile in the correct
directory and then M-xrecompile. But if you want, say to
make clean && make, then you'll have to switch to the correct
directory, do it, switch back.
However term.el has its own drawback, it uses a non-portable hacky
way to track the current directory.
I was figuring out a problem where starting the application from GDB results in a symbol lookup error, but starting it from the shell works.
It turns out that whenever you start a program from within GDB it will start a new shell and thus override all environment variables I had set before starting GDB (like LD_LIBRARY_PATH).
This is not really the behavior I want. Can someone explain the rationale behind this, or tell me how I can turn this off?
I am guessing that you unconditionally set LD_LIBRARY_PATH in your ~/.cshrc or the like. So if from a shell prompt you do this:
export LD_LIBRARY_PATH=foo # or for csh:
setenv LD_LIBRARY_PATH foo
$SHELL -c 'echo $LD_LIBRARY_PATH'
the result is something other than foo. Don't do that.
Usually this happens to CSH users, who neglected to protect their ~/.cshrc against non-interactive shells. It could also happen to BASH users who set their BASH_ENV.
I meet the same problem. I find that in inferior.h (source code of gdb gdb/inferior.h)
there is a macro STARTUP_WITH_SHELL, there is also a piece of comment as
/* If STARTUP_WITH_SHELL is set, GDB's "run"
will attempts to start up the debugee under a shell.
This is in order for argument-expansion to occur. E.g.,
(gdb) run *
The "*" gets expanded by the shell into a list of files.
While this is a nice feature, it turns out to interact badly
with some of the catch-fork/catch-exec features we have added.
In particular, if the shell does any fork/exec's before
the exec of the target program, that can confuse GDB.
To disable this feature, set STARTUP_WITH_SHELL to 0.
To enable this feature, set STARTUP_WITH_SHELL to 1.
The catch-exec traps expected during start-up will
be 1 if target is not started up with a shell, 2 if it is.
- RT
If you disable this, you need to decrement
START_INFERIOR_TRAPS_EXPECTED in tm.h. */
#define STARTUP_WITH_SHELL 1
#if !defined(START_INFERIOR_TRAPS_EXPECTED)
#define START_INFERIOR_TRAPS_EXPECTED 2
#endif
Then I set STARTUP_WITH_SHELL as 0 and decremented START_INFERIOR_TRAPS_EXPECTED
and recompiled my gdb. After that gdb didn't start from shell any more.
When you start gdb from the shell, you start it as a new process, there's no way around that. In Unix new processes inherit some of the environment of the parent.
To make sure a variable is inherited, if you're using a bourne-like shell, try exporting it:
export LD_LIBRARY_PATH=...
The debuggee (inferior in gdb parlance) is always started with a clean environment in order to get more reproducible results. In order to set a variable there, use the
set env VARNAME=VALUE
command before running.
I am tasked with writing a simple shell along with these three commands: "nl", "head", "chroot"(with no parameters). I've written nl.c and head.c but I don't know where to start with the chroot.c. I've read what chroot does, googled some documentation and to me as a beginner this is complicated.
Any advice on this matter?
chroot without an argument just prints an error message. You can use printf for that.
Otherwise, chroot calls chroot, chdir("/") and then executes a shell with one of the exec* functions.
hello everyone
i try to debug a program, which have been installed by makefile.
it have a binary file of OpenDPI_demo.o and a shell shellscript OpenDPI_demo.
when i gdb OpenDPI_demo.o,i have a problem. i can't run it. the error is:
Starting program: /home/lx/ntop/test/opendpi/src/examples/OpenDPI_demo/OpenDPI_demo.o
/bin/bash: /home/lx/ntop/test/opendpi/src/examples/OpenDPI_demo/OpenDPI_demo.o：can't execute the binary file.
please tell me why. actually i can run the program by ./OpenDPI_demo.
thank you.
Based on the extension, the file is an object file. It is used by the linker (alongside other object files) to produce an executable. It's the real executable the one you want to run/debug.
This is another example of difficulties encountered with programs using libtool.
the file OpenDPI_demo alongside OpenDPI_demo.o is actually, as you said, a shell script which wraps the execution of the real compiled file, probably in .libs/OpenDPI_demo.
libtool needs this wrapper to adjust the runtime library paths and such so that you can execute the program transparently, as if it was actually installed on your system.
The way to correctly debug this application is not
/home/lx/ntop/test/opendpi $ gdb src/examples/OpenDPI_demo/.libs/OpenDPI_demo
but rather using libtool --mode=execute on the shell script, like the following (it's an example):
/home/lx/ntop/test/opendpi $ ./libtool --mode=execute gdb --args \
src/examples/OpenDPI_demo/OpenDPI_demo -f capture.pcap
Suggest you use
gdb OpenDPI_demo
instead
In your makefile if it depens on the object, make it depend on OpenDPI_demo, e.g.