Moving to plan9port utilites I can't get used of src utility for executables (for scripts it works fine). It refers to db(1) to get a source file-name from executable in the following way:
% echo 'main?z' | db $1 | <some staff>
where $1 is an executable program name and main?z a special instruction to db(1) debugger to print the file-name with function main.
But in my version of linux (Ubuntu) it doesn't works. db(1) do not produce a file-name, - it just prints the name of procedure: main() and no sources info.
I've tried to compile with 9c -n (I think -n prevents compiler from stripping the code) with no luck.
DWARF-2 is the key:
$ 9c -gdwarf-2 wc.c -o wc.o
$ 9l wc.o -o wc
$ echo 'p9main?z' | db wc
wc: linux 386 executable
no dt_debug section
p9main? p9main() /home/egor/plan9port/src/cmd/wc.c:21
Related
I created simple shell script file in /tmp/test.sh
#!/bin/sh
echo 'aaaa'
In Eclipse->C/C++ Build->Setting->Build Step -> Pre-build steps->Command , I added TEST =/tmp/test.sh
Than in C/C++ Build->Setting->Tool Settings->Cross GCC Compiler ->Command line pattern , I tried to used this variable like -D ${TEST} so it pass -D aaaa (the output of shell script)
But in build console I didn't see that -D aaaa have been passed to gcc , In fact I didn't see -D at all
why is that? I want to set variable in pre-build that will be the output of shell script and use it with gcc command line pattern
How can I do that ?
Apparently the CDT managed build does not allow running external commands for assigning environment variables, build variables or command line flags, thus executing the script at that stage doesn't work.
Not a direct answer to the question on how to do that with the gcc command line pattern, but if you really only want to pass defines to the preprocessor with results you got from the script, you may use the script instead to update or create a header file that is included somewhere, e.g.:
#!/bin/sh
echo "#ifndef __MYVARHEADER__" > ../include/myvarheader.h
echo "#define __MYVARHEADER__" >> ../include/myvarheader.h
echo "#define aaaa" >> ../include/myvarheader.h
echo "#endif" >> ../include/myvarheader.h
In Eclipse->C/C++ Build->Setting->Build Step -> Pre-build steps->Command, just execute /tmp/test.sh
I have a bash script that compiles a program as well on older versions of Ubuntu (14.04.x and 16.04.x) than on the last one (18.04.x) and on other distributions (Arch, CentOS, Debian, Fedora, etc.) and therefore... with different gcc settings.
Then, to obtain an executable that can be launched (among other ways) by a double click, I must compile this program without the "-no-pie" option with older versions of gcc setting (Ubuntu 14.04.x and 16.04.x) when I have to use this option "=no-pie" for the new version of the gcc 7.3 setting (on Ubuntu 18.04.x).
The problem is that on the last Ubuntu release (18.04.x) and its derivatives (Kubuntu, Xbuntu, etc. and maybe with other distributions) with the new configuration of gcc (7.3) having the option "--enable-default-pie", if I compile my program without the option "-no-pie", the result is that the file created is an executable which is of the "shared library" type which can not be launched by a double click.
My question is either:
a) Is there a command that allows me to determine from a bash script if gcc is configured with the "--enable-default-pie" setting?
b) if not, is there a command that allows me to determine from a bash script if the compiled file is of the "shared library" or "executable" type?
For this second option, a solution could be how to save the response of "gcc -v" in a .txt file and check if there is the "--enable-default-pie" string but I've absolutely no clue how to do it.
If I there is not an answer to my first option, the second option (it is true less elegant but just as effective) would allow me to compile my program first without the "-no-pie" option, then check the status of such a created executable and if the result is a "shared library", of restart this compilation this time using the option "-no-pie" for, in one case as in the other, get an executable that can be launched by a double click whatever the setting of gcc may be.
Thank you in advance for your time, ideas and suggestions.
Best regards.
The recommend way to check for PIE support is to compile C code like this
#if defined __PIC__ || defined __pic__ || defined PIC || defined pic
# error PIC is default.
#endif
with the requested compiler flags and check whether there is an error. If you need special treatment for PIE, this will recognize PIE if it has been specified through the CC or CFLAGS variables, even if is not immediately apparent there. For example, for technical reasons, Fedora hides the PIE flags behind a -specs argument.
Yes, you can check GCC build options with gcc -v or gcc -###
In order to have pretty print you can use:
gcc -### -E 2>&1 | grep "Configured with" | sed 's/--/\n--/g'
So bash oneliner to say you have pie or not may be:
if [[ -n "`gcc -v -E 2>&1 | grep 'Configured with' | sed 's/--/\n--/g' | grep enable-default-spie`" ]]; then echo "PIE DEFAULT"; else echo "PIE NOT DEFAULT"; fi
To check file type just use file command, eg.:
file /usr/bin/x86_64-linux-gnu-gcc-7
/usr/bin/x86_64-linux-gnu-gcc-7: ELF 64-bit LSB executable,
x86-64, version 1 (SYSV), dynamically linked, interpreter
/lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0,
BuildID[sha1]=02ac46ba938c15f55f6fab165133e0f527bc2197, stripped
file /usr/lib/libchm.so.1.0.0
/usr/lib/libchm.so.1.0.0: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked,
BuildID[sha1]=7c603d9a0771b5bfd5b869b4446e2f78ef13802a, stripped
File type function
function whatfile { file $1 -i | grep application | sed 's/^.*application\/x-//g;s/,.*$//g'; }
Example output:
aaa#xxx:~ $ whatfile /boot/grub/grub.conf
aaa#xxx:~ $ whatfile /usr/lib/libnss3.so
sharedlib
aaa#xxx:~ $ whatfile /bin/zcat
executable
Unfortunately, comments don't allow CR+LF (to show pre-formatted text).
Below is my formatted translation of your gcc setting command:
check_gcc_setting()
{
if [ -n "`gcc -v -E 2>&1 | grep 'Configured with' | sed 's/--/\n--/g' | grep enable-default-pie`" ]
then
GCC_SETTING="1"
else
GCC_SETTING="0"
fi
read -p "The gcc setting is $GCC_SETTING " GCCRESULT
}
Below is the result:
whatfile { file $1 -i | grep application | sed 's/^.*application\/x-//g;s/,.*$//g'; }
-bash: syntax error near unexpected token `}'
From reading this thread, it looks like its possible to use the shebang to run Rust *.
#!/usr/bin/env rustc
fn main() {
println!("Hello World!");
}
Making this executable and running does compile, but not run the code.
chmod +x hello_world.rs
./hello_world.rs
However this only compiles the code into hello_world.
Can *.rs files be executed directly, similar to a shell script?
* This references rustx, I looked into this, but its a bash script which compiles the script every time (without caching) and never removes the file from the temp directory, although this could be improved. Also it has the significant limitation that it can't use crates.
There's cargo-script. That also lets you use dependencies.
After installing cargo-script via cargo install cargo-script, you can create your script file (hello.rs) like this:
#!/usr/bin/env run-cargo-script
fn main() {
println!("Hello World!");
}
To execute it, you need to:
$ chmod +x hello.rs
$ ./hello.rs
Compiling hello v0.1.0 (file://~/.cargo/.cargo/script-cache/file-hello-d746fc676c0590b)
Finished release [optimized] target(s) in 0.80 secs
Hello World!
To use crates from crates.io, please see the tutorial in the README linked above.
This seems to work:
#!/bin/sh
//usr/bin/env rustc $0 -o a.out && ./a.out && rm ./a.out ; exit
fn main() {
println!("Hello World!");
}
I have written a tool just for that: Scriptisto. It is a fully language agnostic tool and it works with other compiled languages or languages that have expensive validation steps (Python with mypy).
For Rust it can also fetch dependencies behind the scenes or build entirely in Docker without having a Rust compiler installed. scriptisto embeds those templates into the binary so you can bootstrap easily:
$ scriptisto new rust > ./script.rs
$ chmod +x ./script.rs
$ ./script.rs
Instead of new rust you can do new docker-rust and the build will not require Rust compiler on your host system.
#!/bin/sh
#![allow()] /*
exec cargo-play --cached --release $0 -- "$#"
*/
Needs cargo-play. You can see a solution that doesn't need anything here:
#!/bin/sh
#![allow()] /*
# rust self-compiler by Mahmoud Al-Qudsi, Copyright NeoSmart Technologies 2020
# See <https://neosmart.net/blog/self-compiling-rust-code/> for info & updates.
#
# This code is freely released to the public domain. In case a public domain
# license is insufficient for your legal department, this code is also licensed
# under the MIT license.
# Get an output path that is derived from the complete path to this self script.
# - `realpath` makes sure if you have two separate `script.rs` files in two
# different directories, they get mapped to different binaries.
# - `which` makes that work even if you store this script in $PATH and execute
# it by its filename alone.
# - `cut` is used to print only the hash and not the filename, which `md5sum`
# always includes in its output.
OUT=/tmp/$(printf "%s" $(realpath $(which "$0")) | md5sum | cut -d' ' -f1)
# Calculate hash of the current contents of the script, so we can avoid
# recompiling if it hasn't changed.
MD5=$(md5sum "$0" | cut -d' ' -f1)
# Check if we have a previously compiled output for this exact source code.
if !(test -f "${OUT}.md5" && test "${MD5}" = "$(cat ${OUT}.md5)"); then
# The script has been modified or is otherwise not cached.
# Check if the script already contains an `fn main()` entry point.
if grep -Eq '^\s*(\[.*?\])*\s*fn\s*main\b*' "$0"; then
# Compile the input script as-is to the previously determined location.
rustc "$0" -o ${OUT}
# Save rustc's exit code so we can compare against it later.
RUSTC_STATUS=$?
else
# The script does not contain an `fn main()` entry point, so add one.
# We don't use `printf 'fn main() { %s }' because the shebang must
# come at the beginning of the line, and we don't use `tail` to skip
# it because that would result in incorrect line numbers in any errors
# reported by rustc, instead we just comment out the shebang but leave
# it on the same line as `fn main() {`.
printf "fn main() {//%s\n}" "$(cat $0)" | rustc - -o ${OUT}
# Save rustc's exit code so we can compare against it later.
RUSTC_STATUS=$?
fi
# Check if we compiled the script OK, or exit bubbling up the return code.
if test "${RUSTC_STATUS}" -ne 0; then
exit ${RUSTC_STATUS}
fi
# Save the MD5 of the current version of the script so we can compare
# against it next time.
printf "%s" ${MD5} > ${OUT}.md5
fi
# Execute the compiled output. This also ends execution of the shell script,
# as it actually replaces its process with ours; see exec(3) for more on this.
exec ${OUT} $#
# At this point, it's OK to write raw rust code as the shell interpreter
# never gets this far. But we're actually still in the rust comment we opened
# on line 2, so close that: */
I mean something like this:
echo 'main = print 1' | ghc > executable
To which GHC replies: ghc: no input files
Am I missing something? Is this possible somehow?
Even though this isn't possible with normal process substitution, zsh provides a special kind of process substitution-like behavior that allows the "file" to act like more of a real file than traditional process substitution does (by creating an actual temporary file):
% ghc -o Main -x hs =( echo 'main = print 1' )
[1 of 1] Compiling Main ( /tmp/zshjlS99o, /tmp/zshjlS99o.o )
Linking Main ...
% ./Main
1
%
The -x hs option tells ghc to act as though the file name given ends in .hs.
Overall, this is essentially a shortcut around manually creating and deleting a temporary file.
I'm not sure if there are other shells that support this kind of thing. I don't think bash does, at least.
As far as I can tell, the answer is no. My attempts:
$ echo 'main = print 1' | ghc
ghc: no input files
$ echo 'main = print 1' | ghc -
ghc: unrecognised flag: -
$ echo 'main = print 1' | ghc /dev/stdin
target ‘/dev/stdin’ is not a module name or a source file
$ ln -s /dev/stdin stdin.hs; echo 'main = print 1' | ghc stdin.hs
stdin.hs: hFileSize: inappropriate type (not a regular file)
The problems: ghc uses suffixes like .hs, .lhs, or .o to decide what to do with a file (this is why #3 fails). Even if you hack around that (#4), ghc really wants to stat() the file to get its size, which fails on pipes.
Typically ghc is used as a compiler and you run it on files (on which ghc can seek and infer types from endings etc) and specify output files as flags.
You can, however, of course, use
filename=$(mktemp --suffix=.hs)
echo "main = print 1" >> $filename
ghc -o executable $filename
This might not be what you want, but as melpomene already mentioned, runghc can do that. I think it deserves its own answer:
runghc <<< 'main = print 123'
Try it online
I have an executable in which I embed a binary file resource using the objcopy method
objcopy --input binary --output elf32-i386 --binary-architecture i386 data.txt data.o
link to data.o and use
extern char _binary_data_txt_start
extern char _binary_data_txt_end
Is it possible now to update this data inside the executable? The updated data can have the same exact size, I just need to change some of the bits.
In windows PE files this is very simple to do using UpdateResource()
Nothing special and nothing hard at all. I'll give you correct sequence below, but first let me to correct slightly your embedding method. Lets not use objcopy explicitly, lets use GNU LD instead to got correct entry inside ELF file.
Lets begin. This is test-emb.c file:
#include <stdio.h>
extern unsigned char data[] asm("_binary_data_txt_start");
int
main (void)
{
fprintf(stderr, "%u, %u, %u\n", data[0] - '0', data[1] - '0', data[2] - '0');
return 0;
}
This is resource called data.txt
12345678
This is another resource called newdata.txt
98765432
Now compile and link:
$ gcc test-emb.c -c -m32
$ gcc -o test-emb test-emb.o -Wl,--format=binary -Wl,data.txt -Wl,--format=default -m32
Try:
$ ./test-emb
1, 2, 3
Now start dancing. Step one: determine logical and physical address of data section:
$ readelf -S test-emb | grep "\.data" | awk '{print $4}'
080496b8
$ readelf -S test-emb | grep "\.data" | awk '{print $5}'
0006b8
Step two: start and size fo binary data:
$ readelf -s test-emb | grep _binary_data_txt_start | awk '{print $2}'
080496c0
$readelf -s test-emb | grep _binary_data_txt_size | awk '{print $2}'
00000009
Step three: doing math. We do need: find offset of binary data in data, and convert it to physical starting point:
$ echo $((0x080496c0 - 0x080496b8))
8
echo $((0x0006b8 + 8))
1728
Step four: actual replacement (count value is binary data size, taht is 9):
cat newdata.txt | dd of=test-emb bs=1 seek=1728 count=9 conv=notrunc
Now check again:
$ ./test-emb
9, 8, 7
Everything works. You may easily fold this method into script, not harder in use, that UpdateResource under Windows, but I want to give you understanding of how things are going on.
Is it possible now to update this data inside the executable? The updated data can have the same exact size, I just need to change some of the bits.
Sure: just do it:
int main()
{
unsigned char *cp = (unsigned char*) _binary_data_txt_start
cp[0] = 'a'; // change first byte to 0x41
cp[42] += 3; // increment 43rd byte by 3
}
Note: if your _binary_data_txt_start ended up in .rodata, you may have to mprotect the pages on which it resides with PROT_READ|PROT_WRITE first.
Note: if you want the updated data to persist for the next execution of the binary, then harper's answer is correct: just use fopen, seek to correct place in the file, and write the data there.
That leaves the final question: how to find the correct place. If that is your question, see libelf documentation.
When you want to update the date in the binary you will just open the file with a mean you prefer like fopen iostream or what ever.
You can also modify the data when you executable is running. Tho modify the resource in process memory you must be sure that it is in a writable section. Verify this in your MAP file.
You can control the section with --rename-section argument of the objcopy command:
objcopy -I binary -O elf32-i386 --rename-section .rodata=.data data.txt data.o
When you really want to change the content of your elf-file before it is loaded as process than you will have to read the elf header to locate the resource data. It's easier to find the data.txt when you place it in section with a name of its own using --rename-section.
Edit:
The elf file format is too complex to decribe it in just an Stackoverflow answer. You find the basic description and links to the necessary specification here at the Wiki page.
But the easiest way to modify the linker output file is to generate a new version of data.txt and run the linker.