Can the Sys_Execve() System Call in the Linux Kernel Receive Both Absolute or Relative Paths

How to open a file with it's relative path in Linux?

If program is not doing it by itself, it is a bad program. Bad programs should be wrapped with a bit of Bash scripting:

#!/bin/bash

set -e
cd $(readlink -f $(dirname $0))
exec ./myprog $*

The script above determines the directory where it is located, then changes current working directory to that directory and runs a program myprog from there, passing all parameters transparently. Thus, you have to put this script into the same directory where your program is located and run it instead of your program.

Assuming that you have the access to the source code and can fix the program, then use proc fs to determine the program's location and then use absolute path.

For example, /proc/self/exe will always be a symlink pointing at the binary file of the current process. Use readlink to read its value, then cut executable name and you got the directory.

How is Linux kernel live debugging done and what tools are used?

Another option is to use an ICE or JTAG controller, and GDB. This 'hardware' solution is especially used with embedded systems.

But for instance QEMU offers similar features:

• start QEMU with a GDB 'remote' stub which listens on 'localhost:1234' : qemu -s ...,

• then with GDB, you open the kernel file vmlinux compiled with debug information (you can take a look a this mailing list thread where they discuss the unoptimization of the kernel).

• connect GDB and QEMU: target remote localhost:1234

• see your live kernel:

    (gdb) where
    #0  cpu_v7_do_idle () at arch/arm/mm/proc-v7.S:77
    #1  0xc0029728 in arch_idle () atarm/mach-realview/include/mach/system.h:36
    #2  default_idle () at arm/kernel/process.c:166
    #3  0xc00298a8 in cpu_idle () at arch/arm/kernel/process.c:199
    #4  0xc00089c0 in start_kernel () at init/main.c:713
  

Unfortunately, user-space debugging is not possible so far with GDB (no task list information, no memory management unit reprogramming to see different process contexts, ...), but if you stay in kernel-space, that's quite convenient.

• info threads will give you the list and states of the different CPUs

You can get more details about the procedure in this PDF:

Debugging Linux systems using GDB and QEMU.

Running executables present in the PATH environment using execve

envList={"/bin",NULL}

This is incorrect. envList provides the environment strings for the exec-ed program; it is not a search list or a path list. A correct envList would be more like

envList = { "HOME=/root", "PATH=/bin:/sbin", NULL }

gcc without full path: error trying to exec 'cc1': execvp: No such file or directory

I solved this problem with simple solution.

export PATH

After this command, compile with relative path will be succeed.

---

Roads to found this:

• I test if add PATH to libexec can compile.

$ PATH=${PATH}:/usr/libexec/gcc/i686-test-linux/8.3.0/ -> Successful

According to strace log, I think gcc does not use $PATH to search cc1/cc1plus. Why?

• I test if PATH to /usr/bin can compile. (by mistake)

$ PATH=${PATH}:/usr/bin -> Successful

• Why this success? I think PATH already contains "/usr/bin"

$ echo ${PATH}
/sbin:/usr/sbin:/bin:/usr/bin

• I test if passed $PATH simply.

$ PATH=${PATH} gcc -> Successful

• What the difference between $ gcc and $ PATH=$PATH gcc???

$ set
HOME='/'
HOSTNAME='TEST0'
IFS='
'
LINENO=''
OLDPWD='/'
OPTIND='1'
PATH='/sbin:/usr/sbin:/bin:/usr/bin'
PPID='2701'
PS1='\w \$ '
PS2='> '
PS4='+ '
PWD='/'
SHLVL='8'
TERM='linux'

$ export
export HOME='/'
export OLDPWD='/'
export PWD='/'
export SHLVL='8'
export TERM='linux'

Oh, PATH is not exported as environment variables. only existed as shell variables...

---

Related Topics