Index
> Linux > Debugging FASM x86-32 with gdb on Linux |
| Author |
|
|
egy 10 Aug 2017, 17:48
According to this thread: Symbolic/debug information, I cannot yet debug fasm executable simply with gdb or any other debugger on x86 Linux. Is my assumption valid ?
If it is, could any one please point me out to another way to debug FASM on x86 Linux ? I am willing to use/learn any debugger. |
|||
10 Aug 2017, 17:48 |
|
|
egy 10 Aug 2017, 20:48
My new hello world code receives SIGFAULT and I wasn't able, at the assembly level, to figure out where was the error from. I am currently learning, but I am not finding more materials for learning though. I might quit at the end.
I was digging the forum for an answer, and found this one by Endre: Endre wrote: It may sound a blasphemy here on this forum, but if you're using fasm instead of practically any other assemblers on Linux then you'll be in trouble. It is because fasm is unable to generate standard debug info (like e.g. DWARF2) which is necessary for debuggers. Of course in tricky ways you can debug your code even without debug info, but it's far from convenient. Seems logical to me. I won't write bigger assembly programs though. EDIT: I am trying to install ALD. As far as I have seen, it offers the basic functionality I need with assembly code. Hope I can get it to work. |
|||
|
10 Aug 2017, 20:48 |
|
|
system error 10 Aug 2017, 23:31
You haven't looked hard enough.
There's debugger by Feryno's (FDBG) (64-bit version) https://board.flatassembler.net/forum.php?f=21 And there's also Evan's Debugger (EDB) for linux which has a good resemblance with Olldbg. http://www.codef00.com/projects#debugger But really, if you have problems with your code, your first natural option should be to share the faulty code with us so we can offer you assistance where possible. Human debuggers can tell you a lot more than gdb. |
|||
|
10 Aug 2017, 23:31 |
|
|
egy 11 Aug 2017, 06:44
Quote: There's debugger by Feryno's (FDBG) (64-bit version) Of course, Feryno's debugger is an impressive project. Alas, my machine is 32-bit. Evan's debugger looks mature. If it offers basic functionality to debug FASM's code, then I would be very glad. I got some problems yesterday with ALD not compiling, so I'll look into it after that. |
|||
|
11 Aug 2017, 06:44 |
|
|
Furs 11 Aug 2017, 11:52
Well let me know if you find a debugger that uses FASM debug symbols so I can store & bookmark it, cause I've never really relied on symbolic information when debugging asm.
|
|||
|
11 Aug 2017, 11:52 |
|
|
system error 12 Aug 2017, 00:33
egy wrote:
I never personally use any debugger on Linux. All I need is "printf" from GCC to see what's going on at one particular problematic spot in my code and a good understanding of what exactly I'm dealing with. Is it memory? Stack? internal structure? registers? syscall? You can do it with "printf" as the main investigating tool. It's like a Swiss-Army Knife. It builds strong characters ;D But people are different. I respect that differences. And tbh, FASM doesn't have such symbolic debugging luxuries (just yet) on Linux. But if you're willing to take that scenic route dealing with bits and pieces, FASM is the best way to go. |
|||
|
12 Aug 2017, 00:33 |
|
|
Furs 12 Aug 2017, 16:16
Yeah, printf is a very common "basic debugging" tool that I personally use especially with plugins (kind of annoying to set the debugger up then)... but it's not very informative for someone who wants to step through the asm to learn what went wrong (step through each insn and look at effects). I'm guessing the OP isn't so proficient in Linux programming.
But for a SIGFAULT I don't see why you need symbolic information at all. egy can you please show on what instruction exactly does it trigger the SIGFAULT and the surrounding code? |
|||
|
12 Aug 2017, 16:16 |
|
|
egy 13 Aug 2017, 17:12
Ok, so lots of things happened since the last post. Chronologically:
1- Compiled ALD but couldn't use it (I'll give it a shot next time) 2- EDB is great! (though dependencies + build >200MB). The disassembly view allowed me to inspect each instruction. There were more than one bug. Quote: egy can you please show on what instruction exactly does it trigger the SIGFAULT and the surrounding code? IIRC, it was from an int 0x80 with wrong eax value. I wasn't also aware that repnz or its family increases ecx for each successful iteration. The Intel® Full Instruction Manual was truly my friend 
3- Today, I finally got gdb to work with assembly. It seemed clear and obvious to everyone how to use it, but it wasn't for me. The bottleneck was to get gdb to set a breakpoint on the main function. However, for a compiled exec. with no linker, the command Code: (gdb) break _main #or _start,main,start I had to get the entry point of the exec. via the ELF header and give it to gdb, simply issue[0] Code: readelf -h your_exec | grep Entry Code: b *0x0804... Quote: All I need is "printf" from GCC That's the most natural and first behaviour to debug your code. But, if machines already do it for me nicely (i.e. printing out all sorts of information), why not use that instead ? Also, the main point was to learn how to use a debugger, be it gdb, edb, or any major one. Quote: but do you really need symbols for an assembly program debugging though? Can't you just look at the instructions and recognize the pattern? i.e. debug without debug symbols. Furs: It seems I didn't understand you from the beginning. Could you please explain to me what is debugging with debug symbols (sorry if this sounds redundant) ? Is it like having every function labeled and be properly read by a debugger ? All I wanted to do was to view my code (here, instructions) and step through them while printing various information, which I happily acheived today with gdb. [0]: https://stackoverflow.com/a/36165001/3238316 Last edited by egy on 13 Aug 2017, 17:17; edited 1 time in total |
|||
|
13 Aug 2017, 17:12 |
|
|
Furs 13 Aug 2017, 17:16
Symbolic information is stuff like variable names, function names etc. Those are "symbols". The reason you couldn't use _main is because there is no _main symbol (I guess?) since no debugging information and _main isn't an exported function. It's a short-hand for specifying the entry-point anyway.
Debugging symbols don't exist in the compiled output file, so all function names/var names are lost. Only their addresses remain. However, some symbols remain -- imported functions for example. Because the ELF loader uses their names to resolve them from other .so files. They're named already and embed in the code without any debugging information (that's how the ELF loader is able to resolve them), and those are the most important since they're not "your code" but they allow you to see easier what pattern of code it is (the rest is your code, so you should be able to pinpoint where in the source it is). But yes, debugging is very useful when you are a bit inexperienced and want to step-through each instruction to see how it works exactly -- very handy. Glad you got it sorted.  |
|||
|
13 Aug 2017, 17:16 |
|
|
egy 13 Aug 2017, 17:42
Furs wrote: -- imported functions for example. Because the ELF loader uses their names to resolve them from other .so files. like some C libraries, for example ? I remember I saw a few function calls I didn't made when debugging with edb. Furs wrote: But yes, debugging is very useful when you are a bit inexperienced and want to step-through each instruction to see how it works exactly -- very handy. Glad you got it sorted Thank you. Hope I get more advanced soon. By the way, I should have added that (gdb)break _main didn't work only when compiled with FASM directly (i.e. setting the first line to be executable and working with segments). When compiled and linked with ld, it recognizes _main instantly and no problems are present with debugging. |
|||
|
13 Aug 2017, 17:42 |
|
|
Furs 13 Aug 2017, 21:28
Yes, like C libraries -- since they're just .so files. I mean, every library must export its functions, and they do it by name (symbols). Those are visible (and needed) even without debugging.
ld might be adding the symbol, the default script is kind of complicated (not small at all), adds a lot of frivolous stuff too  |
|||
|
13 Aug 2017, 21:28 |
|
|
Endre 02 Sep 2017, 12:09
So when you're about to use fasm on linux just recall this little code snippet
Code: /** * Compile with * gcc -g -nostdlib hello.S -o hello */ .if 0 #include <unistd.h> #include <sys/syscall.h> .endif .line __LINE__ .intel_syntax noprefix .text .globl _start _start: mov eax, __NR_write mov edi, STDOUT_FILENO mov rsi, offset message mov edx, offset message.size syscall xor edi, edi mov rax, __NR_exit syscall message: .ascii "Hello world\n" message.size = . - message and that you merely have to issue the following commands Code: gcc -g -nostdlib hello.S -o hello gdb ./hello b _start r ... and you're done. That's it. You can include c-headers, you can debug your code. Believe me there is very little need of complex macros for which you'd need fasm. Macros you really need can be written either as c-macros or gnu-as macros. |
|||
|
02 Sep 2017, 12:09 |
|
|
Endre 02 Sep 2017, 14:00
And one more thing. If you don't like that gnu tools create a bit bigger binary (comparing to that created by fasm) you can use sstrip from ELFkickers
|
|||
|
02 Sep 2017, 14:00 |
|
|
Furs 02 Sep 2017, 14:50
Is there a difference between sstrip and strip -s?
|
|||
|
02 Sep 2017, 14:50 |
|
|
Endre 04 Sep 2017, 08:44
yes there is, sstrip generates smaller binary. Even strip -s is not the best option. With strip -R section_name you can remove sections you don't need, but even then sstrip is a bit more effective. On the other hand fasm is unbeatable in this regard.
|
|||
|
04 Sep 2017, 08:44 |
|
< Last Thread | Next Thread > |
Forum Rules:
|