C program for MIPS74kc never returns - c

I have a simple C "Hello world" program, compiled using GCC toolchain for mips74-kc running a Linux S/O (kernel 3.10.36)
#include <stdio.h>
int main() {
printf("Hello world\n");
return 0;
}
The program is compiled on a x64-86 Ubuntu machine, as I don't have GCC available on the MIPS machine. I compile the program with the static linking flag.
mips-linux-gnu-gcc --verbose -static -march=74kc main.c -o main
When I launch the program on the MIPS processor, the program holds and never returns, consuming 100 % of the CPU.
Does anyone have a clue on why this could happen?

Related

Shellcode to execute a shell results in a segmentation fault

I am trying to run this code to get a shell but I am getting a segmentation fault even with ASLR disabled. I am running this code on my AMD Ryzen 3 computer with Ubuntu 20.04 64bit version.
I am compiling with the following command:
$ gcc -O0 -fno-stack-protector -z execstack getshell.c -o getshell
File getshell.c is as following:
#include <stdio.h>
unsigned char shellcode[] = \
"\x48\x31\xf6\x56\x48\xbf\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x57\x54\x5f\x6a\x3b\x58\x99\x0f\x05";
int main()
{
int (*ret)() = (int(*)())shellcode;
ret();
}
Edit: I found this piece of code here
unsigned char __attribute__((section(".text#"))) shellcode[]
works for me (mind the #)
# is a trick - it comments part of the emitted assembly code by gcc.

Why am I getting the error "undefined reference to main" even though main is properly defined?

I am running Xubuntu on a vm (because it was easier to do that compared to getting gcc on windows).
I have tried all of the different arguments for compiling the program (eg. running gcc filename.c and gcc filename.c -o filename), but none of them have changed the outcome.
My code is:
#include <stdio.h>
int main(void) {
printf("a");
return 0;
}
I've tried using main() and main(arg...[or whatever it is I can't remember]) and I get the same error.

How should I write code for -nostartfiles or -nostdlib options for gcc?

I came across -nostartfiles and -nostdlib options under gcc compilation options. I, however, do not understand as to how one can write code for the above options. Do you need to write every startup function (like _start, __libc_csu_init etc.)?
Can I get a simplified code for both these options just to understand it's working?
Edit:
Also I just discovered that using static along with nostartfiles throws a segmentation fault. A simple c code to reproduce the same:
#include<stdio.h>
#include<stdlib.h>
void _start()
{
int x = main();
exit(x);
}
int main()
{
printf("Hello world!\n");
return 0;
}
Compiled using:
gcc -nostartfiles -static -o foo foo.c
The output to the above code is a segmentation fault. Is it the expected output?
Yes, this is expected behaviour.
If you want to write your own startup-code or your own standard library, you need these options, otherwise you could not write your own code as symbols would be duplicated.

Cross compiling pdcurses from arch linux to windows

I'm trying to cross-compile a simple "Hello World!" program, from arch linux to windows
Here's the code:
#include <stdio.h>
#include <curses.h>
int main() {
initscr();
printw("Hello World!");
refresh();
getch();
endwin();
return 0;
}
And then I compile using mingw:
x86_64-w64-mingw32-gcc hello.c -o hello-x64.exe -lpdcurses.dll
And when I run the program, it crashes. Here's it's trace
Make sure you're including the curses.h from the PDCurses package, and not the system curses.h (which is ncurses).
Also, although it's probably not relevant to the problem, stdio.h is not needed here.

what is the case when a programe can run as normal but not in gdb?

I have a programe, which is so simple. The code as below.
I compiled it with
gcc -g -Wall -I../software/libxml2-2.9.0/include/
-lxml2 -L/usr/lib test.c -o test
I can absolutely run it with "./test", but when I run it with "gdb test" and then print "run" it will receive signal SIGSEGV. So I want to know what happened?
#include <libxml/xmlreader.h>
int main( void )
{
const char *file = "/usr/share/mime/application/javascript.xml";
xmlNewTextReaderFilename( file );
return 0;
}
If you are debugging using gdb test you may actually be debugging /bin/test rather that your own program. If the backtrace does not correspond to your expected program switch to gdb ./test (in a similar manner to how you are running the program as ./test)

Resources