I have seen a document here http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file. This example is all about crash seen in Windows file? I am looking for the same mathematics that has been done here for the crash generated on Linux systems. If I get the crash on Linux, then how will I debug the issue in the similar lines like Microsoft document http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file. Please help?
Is load address and the code segment address are same in Linux? what is the following in Linux as mentioned in the link "The first part of the binary is the Portable Executable (PE), which is 0x1000 bytes long."?
PE is windows format. Linux uses ELF. Of course you can parse ELF manually, but you shouldn't - gdb could do that for you. Even more, you can use addr2line utility to map address to file/line in source code (of course both of these will require debug build).
Map files are rarely used in linux - it usually just a part of debug executable. It could be dumped from debug build, however, but it don't have too much practical value.
Also, take a look at How to use addr2line command in linux
Related
I have a x86_64 machine, and it can run IA32 process because I have installed a 32bits library. Now I want to know what's the platform that a running process is using? 64bits or 32bits?
The only way I can access the process is a ptrace system call; I don't have executable file (like I can just execute the file but I don't have read and write permissions), so I can't get the ELF header.
The OS I'm using is Ubuntu 14.04 LTS.
I don't want to get executable file, and then analyse the ELF format. The ONLY WAY I can access the process is ptrace, or other system calls same as ptrace if you know, please tell me. Because I want to analyse the process in a C program.
This was also asked on https://unix.stackexchange.com/questions/106234/determine-if-a-specific-process-is-32-or-64-bit, with limited success / viability for detection methods other than checking ELF headers after getting to them in various ways.
Looking at /proc/<pid>/maps for 64-bit addresses looks viable. So does checking the bitness of /proc/<pid>/exe:
$ file - < /proc/$(pidof a.out)/exe
/dev/stdin: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=ff6b5084918be4e4daf7e4315fa4d6dd6a039ae7, for GNU/Linux 4.4.0, with debug_info, not stripped
(Or file -L to follow symlinks. If you just use file /.../exe, it tells you symbolic link to /tmp/a.out.)
Note that files in /proc track the actual inode, so replacing /tmp/a.out with a different executable does not throw this off. Opening it for reading will open the actual executable that this process has mapped, separate from the name it would report via a readlink() system call. If that inode has no directory entries anymore, file will report symbolic link to /tmp/a.out (deleted), but opening for reading will still get the contents. And renaming a.out will get the kernel to report the new name as the symlink, like /tmp/bar.
This answer previously suggested looking at /proc/<pid>/personality, but the difference I was seeing was that a 32-bit process had the READ_IMPLIES_EXEC bit set. That's likely because I built a 32-bit executable from asm sources I had been playing with at the time, without the .note.GNU-stack,"",#progbits that overrides the default of executable stacks, previously implemented by making all pages executable: Unexpected exec permission from mmap when assembly files included in the project
A 32-bit executable compiled by gcc -m32 has personality 00000000, same as 64-bit /bin/sleep. So this isn't a useful detection mechanism, unfortunately. I was hoping that 32-bit processes would have some bits set like ADDR_LIMIT_32BIT, but apparently that's implicit for a 32-bit process, perhaps as part of the "execution domain" like PER_LINUX32.
I got 00400000 (just READ_IMPLIES_EXEC) for a 32-bit process with executable stacks (and everything else). (And 00440000 when I had it stopped in a debugger.) The proc(5) man page says it tells you the personality as set by personality(2).
Kernel source for personality bit-numbers: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/personality.h
glibc's copy: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/sys/personality.h;hb=HEAD
Mostly leaving this part of the answer here in case the part about decoding personalities is useful to future readers. It's not relevant to finding the bitness of a running process.
Try using xocopy to create a copy of the executable in question and dump the ELF header from the copy created.
This tool and the problem you are describing was discussed elsewhere and that discussion may be helpful to you as well.
I'm asking this because I've been given a task which I don't yet know how to handle. You see, we're in a situation where we can execute legacy a.out programs on a virtual machine running a really old linux kernel. We would like the native MinGW gdb to debug the program somehow. It's been proposed that we convert the a.out file into a PE file containing debug symbols and send it to GDB to process, while actually running the UNIX a.out file on the virtual machine. The only available debug symbols that comes with the a.out file is STABS, since the version of GCC used on the VM is very old.
I understand that it's possible to add STABS debug information into a PE file. GCC does it, and I've done experiments with objdump and gdb comprehensively enough to come to to the conclusion that STABS works with MinGW GDB. So how do I achieve it? How did GCC approach it?
Thank you.
I played a little bit with nice library called libmonkey which gives nice interface for dynamic ELF patching on Linux. However, I'm trying to run it on FreeBSD; compilation passed, but I'm getting core dump in runtime (gdb is pointing header offset calculation code).
I'm not familiar with ELF, but aren't headers should be the same on linux and freebsd?
Anyone have idea what is happening?
Thanks
I am currently working with some µC systems and I'd like to go deeper into detail to understand what is going on beneath.
I am currently working with a Motorola Coldfire and an ARM 9. For both I am using the GCC toolchain as a cross compiler!
ELF files contain more information than needed to get the application run! A BIN file would be enough though! I know the ELF format keeps some extra information. it concatenates symbols and their addresses in memory, right? Are the extra information for the software debugger (e.g. GDB) only or are some of theses information transfered to the target device as well? So if there is a breakpoint hit, the on-chip debugger tells the host the regarding address and the software debugger can show me the relevant code section instead of the boring memory address only?
Can I debug using a BIN file only (Ok this would be stupid, but basically?)?
Some enlightenment regarding this topic is appreciated!
thynk you
You are right that ELF files contain extra information, such as symbols used for debugging. Typically in a µC environment, you will use the BIN file to execute on the processor (usually loaded into flash) and then you would pass the ELF file to GDB for debugging. When running the cross-compiled GDB on your development PC, it will use the ELF file for reference (so it knows code line numbers, variable names, etc.) but it will communicate with the on-chip debugger to read memory locations, set breakpoints, etc. To get GDB to communicate with the on-chip debugger, you use the target remote command in GDB, passing it whatever parameter is necessary (often a serial port of network address & port).
This is a hard question to ask because I'm positive I'm about to be bombarded with haters commenting on "if I can't write an operating system already, I won't ever to be able to write an operating system". Well I've read Modern OS by Tanembaum, Linux Kernel Development, Understanding the Linux kernel and others I still don't know if or not I can write an operating system and only by pushing forward to write one will I realise what I don't know. On top of that none of the books I read even bother to describe the boot sequence / compilation sequence.
Anyway I hate to be negative but I would just like to build the example code from the bkerndev tutorial below and have an absolutely minimum operating system:
http://www.osdever.net/bkerndev/index.php?the_id=90
You can download the associated source code in a zip format from here:
http://www.osdever.net/bkerndev/bkerndev.zip
When you try and compile this kernel you run into all sorts of errors caused by the fact that some of the code is broken. Another user was seeking help for this here on stack overflow here:
compiling my own kernel (not from linux-kernel source)
Although didn't get much help. I have addressed those errors by adding the gcc flag fleading-underscores and by changing some of the data types. You can see my code here:
http://github.com/PhillipTaylor/farmix
The code will compile sucessfully and leave me with a kernel.bin executable but when I boot into it from grub I get:
Error 13: Unrecognised or unsupported format (or something to that nature)
When I take the kernel.bin directly from the authors zip file and run it on my eeepc it boots absolutely fine so I think I have a problem with compiling the code correctly. The author is building it from a Windows machine, I believe, but I am trying to compile it using Fedora 10 i386 with GNU GCC 4.3 and I think this is what is causing the issue so I ask you, how do I build a valid executable kernel? Am I missing the correct target or the wrong binary format?
I would really appreciate someone helping me over this embarrassing "first step"
My comment above wasn't very clear. What I meant is "What does the 'file' command report on your kernel.bin vs. theirs?". The output of the linker is a raw binary file. It should start with a few magic words that grub recognizes. They are defined in start.asm near "mboot". I suspect yours is different than theirs.
I don't have nasm handy so I can't build, but you might want to start by comparing the first few words of the .bin file.
It turns out that the line used to compile the app was explicitly set to compile to "aout" format which was what the guide said and what I assumed to be true. Only reading stuff in the "barebones" guide convinced me that I may have been confused. As soon as I changed that one line to "nasm -f elf" it all worked.
This is a tag in my repository that points to a basic WORKING version of bkerndev tutorial code (How to write your own Operating system) for future reference and people who were in my position..
It comes with a makefile for building it from a 32 bit Linux system.
http://github.com/PhillipTaylor/farmix/tree/bkerndev_tutorial_working