flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Linux > Debugging FASM x86-32 with gdb on Linux

Author
Thread Post new topic Reply to topic
egy



Joined: 01 Aug 2017
Posts: 13
Debugging FASM x86-32 with gdb on Linux
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.
Post 10 Aug 2017, 17:48
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 867
Sorry I can't help, 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.
Post 10 Aug 2017, 20:31
View user's profile Send private message Reply with quote
egy



Joined: 01 Aug 2017
Posts: 13
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.

So if you're about to write bigger assembly programs on Linux I advise to change to other assembler which can generate proper debug info. On Linux the host debugger is gdb, nothing else. Learn it.

Not debugging is not an option for sane people.



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.
Post 10 Aug 2017, 20:48
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 667
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.
Post 10 Aug 2017, 23:31
View user's profile Send private message Reply with quote
egy



Joined: 01 Aug 2017
Posts: 13

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.
Post 11 Aug 2017, 06:44
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 867
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.
Post 11 Aug 2017, 11:52
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 667

egy wrote:

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.



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.
Post 12 Aug 2017, 00:33
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 867
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?
Post 12 Aug 2017, 16:16
View user's profile Send private message Reply with quote
egy



Joined: 01 Aug 2017
Posts: 13
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 Cool
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:
(gdbbreak _main    #or _start,main,start

did not yield anything.
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

then launch gdb and set a breakpoint there:

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
Post 13 Aug 2017, 17:12
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 867
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. Smile
Post 13 Aug 2017, 17:16
View user's profile Send private message Reply with quote
egy



Joined: 01 Aug 2017
Posts: 13

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.
Post 13 Aug 2017, 17:42
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 867
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 Razz
Post 13 Aug 2017, 21:28
View user's profile Send private message Reply with quote
Endre



Joined: 29 Dec 2003
Posts: 211
Location: Budapest, Hungary
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     ediSTDOUT_FILENO
        mov     rsioffset message
        mov     edxoffset message.size
        syscall
        xor     ediedi
        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.
Post 02 Sep 2017, 12:09
View user's profile Send private message Reply with quote
Endre



Joined: 29 Dec 2003
Posts: 211
Location: Budapest, Hungary
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
Post 02 Sep 2017, 14:00
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 867
Is there a difference between sstrip and strip -s?
Post 02 Sep 2017, 14:50
View user's profile Send private message Reply with quote
Endre



Joined: 29 Dec 2003
Posts: 211
Location: Budapest, Hungary
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.
Post 04 Sep 2017, 08:44
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.