flat assembler
Message board for the users of flat assembler.

Index > Heap > I am done with Linux Assembly!

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
system error



Joined: 01 Sep 2013
Posts: 671
system error
This is my personal opinion and nothing to do with FASM. I am new comer to linux assembly and assembly programming (I code in Java and SQL mostly for work, assembly during spare time). After the first few attempts to get to know Linux assembly programming, it's a no go for me. Here's why;

1. Linux is so cursed with C. C is the center of the universe for Linux. For almost every step, you'll have to deal with C this and C that. Makes me sick! Don't get me wrong baby, C is a great language. But when new comers have to deal more with C than with assembly then they are better off using C! There's no point learning assembly in Linux. Because in Linux, C is sort of a virtual machine to Linux kernel just like Java uses a virtual machine! LOL

2. syscall is too register-intensive to my liking. You have to use 4 to 5 precious registers just to print 'A' to stdout. You can't simply put a character in a register and display its value. Your precious character must reside in memory - that means for every PROC, you must reserve a local stack space even if you are dealing with just a single char. Really is unnecessary increase in code size and memory. That tend to bloat!

3. Community support? LOL. You won't get such luxury from Linux community. The best advise they can offer you "Why don't you use C, why bother hand-coded it in assembly? C knows best for your code... oh there's intel's intrinsics to help u around SSSE...bla bla bla". C is a HLL you moron!

4. Tools? Yes almost every tools in Linux are C-based! Even the gdb is C-based - works best for C codes, with AT&T syntax of course! Don't ask why there isn't one decent debugger for Linux out there, because tool developers don't want to deal with C in every step of their way! C stack, C's conventions, C's memory management, C's macro, C's string, C's this and C that. In short, Linux wants you to see the machine codes from C's point of view! That what's keeping tool developers away from Linux.

So for new comers who wants to learn assembly language AND the machines, Linux is not for you. Windows/FreeDOS/DOS offers more freedom and get you closer to the machines from assembly's POV. There's also Rasp Pi for you. Plus, you get to use more tools and get more support from the community. Even Windows 10 now is bringing back the good old command prompt because M$ know how important it is for the developers / assembly programmers to see the content of the registers via good old fashion DEBUG!

For those sayin DOS prompt is nothing compared to Linux's terminal, well Fcuk you! DOS was first designed to interface electronic devices at hand - port, memory, partition, hard disk, video, DEBUGGING, BIOS access etc etc. I feel much closer to the machines with DOS prompt than with Linux terminal.

There, I said it. I don't know about other platform, but this one is for x86 only. Take it or leave it. Hahaha Twisted Evil

p/s This has nothing to do with Linux as an OS. Linux and the distros are GREAT OSes.
Post 28 Oct 2014, 20:32
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
Hahaha Twisted Evil
Post 28 Oct 2014, 20:41
View user's profile Send private message Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens
well.. C was made to be portable assemby

as for debugging under linux, i agree
i use fdbg if needed although there is no call stack
(and fasm needs full elf support Smile)

bdw, linux kernel and C calling conventions under amd64 are fastcall


hope you can come back some time
if you needed help to start you could have asked here

PS objdump has a flag -M intel for intel syntax
i'm sure gdb can do the same (i think it uses objdump anyway)
Post 28 Oct 2014, 20:42
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
gens wrote:
well.. C was made to be portable assemby

as for debugging under linux, i agree
i use fdbg if needed although there is no call stack
(and fasm needs full elf support Smile)

bdw, linux kernel and C calling conventions under amd64 are fastcall


hope you can come back some time
if you needed help to start you could have asked here

PS objdump has a flag -M intel for intel syntax
i'm sure gdb can do the same (i think it uses objdump anyway)


hahaha. Nothing personal gens. It's just that I think that Linux isn't as natural when it comes to assembly programming. Maybe its just me. LOL.
Post 28 Oct 2014, 20:54
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
And then there is syscalls! (no offense to gens)

You know what, there is no assembly definitions for syscalls. All are documented in C's API! That means there is no way you may know what registers got scratched inside those functions. This gets worse in AMD64 because there is no PUSHAD instruction anymore!!

e.g, to display the string (syscall uses eax,esi,edi,edx). That's what they tell you in the ABI. Well, guess what happen to RCX? Yeap, that function scratches RCX and won't restore RCX for you. Hello nasty bugs!!
Post 28 Oct 2014, 21:17
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
What to say?

1. It is simply not true. In Linux you can make everything without calling C functions and linking to C libraries. The system calls are absolutely enough. As long as this is the only interface to the kernel, C libraries do all its functionality using the same sys calls as your assembly program.

2. Use your own small wrappers, as I do in FreshLib. Or use FreshLib - it will make your programs compilable for Windows and Linux in the same time. And it have really assembly-centric interface. "no-more-c-call". Wink

3. Partially true. But using system calls, you actually don't need help from C programmers. Fortunately, there is an excellent reference: LSCR help files.

4. Ask me about tools! Smile GDB sucks with all its front-ends and back-ends. Greatest debugger for Linux is EDB. It is almost Olly for Linux. Check it! Fresh IDE of course for a great IDE+FASM compiler. In fact I am working 100% of time in Linux now (when in home) and I don't miss tools for Linux. I almost never use console tools in Linux at all. (Well, except fossil scm, but it has really great console interface).
Post 28 Oct 2014, 21:26
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
gens



Joined: 18 Feb 2013
Posts: 161
gens
i went for amd64 abi straight away
http://www.x86-64.org/documentation/abi.pdf is a very good documentation

http://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI gives an overview
and http://www.logix.cz/michal/devel/amd64-regs/ shows things nicer and is what i go to when i forget what goes where


don't worry about me Smile
Post 28 Oct 2014, 21:31
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
John and gens....

I'll have a look at those resources before I completely give up on Linux (our server is on FreeBSD though hehehe). Those links should be stickied in the Linux section. IMO.
Post 28 Oct 2014, 21:46
View user's profile Send private message Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 730
tthsqe
Why don't you come over to windows? I think it is very comfortable. There is fdbg on this forum, and you have a suggestions for the debugger, I can probably work them into a modified version. Also, after about 10 years, 64 bit ollydbg is in the works...
Post 29 Oct 2014, 02:36
View user's profile Send private message Reply with quote
Foxxy



Joined: 14 Jul 2014
Posts: 42
Location: Somewhere over the rainbow...
Foxxy
For Linux assembly, I suggest buying a RasPi and using these tutorials: http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/
Post 29 Oct 2014, 04:10
View user's profile Send private message Reply with quote
redsock



Joined: 09 Oct 2009
Posts: 364
Location: Australia
redsock
FWIW, I have spent many thousands of hours so far doing linux x86_64 assembly using fasm, and am _soooo close_ to doing my actual business model GPLv3 release of same it isn't funny (haha, ok, maybe it is).

While I appreciate what you are saying, having done so much of it, I think you are missing the larger point, and I must agree with JohnFound's sentiments that really, all libc does is make "programmer-friendly" wrappers around syscalls. In the entirety of my library thus far, there are only 216 syscalls, and of those 216, only ~80 or so are unique.

I don't agree with JohnFound's gdb hatred, but only because I am happy to include framepointers by default for all of my goods, which makes debugging with gdb a pleasure, not a pain.. haha

Just doing finish-work with my library itself, and making sure that the GPLv3 headers/license/copyrights that I need to include are correct before I turn it all loose to you guys, won't be long...

As at right now though, to give you some idea of just how far I have gone with it, here is a wc --lines of the library itself:

Code:
   1322 aes.inc
    142 align_macros.inc
    431 base64_latin1.inc
  10906 bigint.inc
    275 blacklist.inc
      7 breakpoint.inc
   1165 buffer.inc
     62 call.inc
     41 cleartext.inc
    480 crc.inc
     24 dataseg_macros.inc
   1104 date.inc
     24 dh_groups.inc
    113 dh_pool_16k.inc
    137 dh_pool_2k.inc
    137 dh_pool_3k.inc
    137 dh_pool_4k.inc
    137 dh_pool_6k.inc
    137 dh_pool_8k.inc
     55 dh_pool.inc
    147 epoll_child.inc
    897 epoll_dns.inc
   2752 epoll.inc
    759 fcgiclient.inc
    334 file.inc
   2067 formatter.inc
    847 heap.inc
    648 hmac.inc
    565 htcrypt.inc
    149 htxts.inc
    243 io.inc
   1617 json.inc
    824 list.inc
    601 mappedheap.inc
    423 mapped.inc
   4464 maps.inc
    976 math.inc
    502 md5.inc
   1712 memfuncs.inc
   2566 mimelike.inc
    273 pbkdf2.inc
    751 png.inc
     12 pod_data.inc
    319 pod_defaults.inc
    552 pod.inc
    211 privmapped.inc
   1267 profiler.inc
     64 rc4str.inc
     23 rdtsc.inc
   1042 rng.inc
    411 scrypt.inc
    610 sha1.inc
   1981 sha2.inc
     35 sleeps.inc
   5572 ssh.inc
   4341 string16.inc
   4376 string32.inc
   2138 string_math.inc
    321 syscall.inc
     43 sysinfo.inc
    274 syslog.inc
   5272 tls.inc
    499 tui_alert.inc
   1192 tui_ansi.inc
    243 tui_background.inc
    145 tui_bell.inc
    274 tui_button.inc
    388 tui_datagrid.inc
    195 tui_debugger.inc
    993 tui_effect.inc
   1016 tui_effects.inc
    760 tui_form.inc
    464 tui_geometry.inc
   1050 tui_gridguts.inc
    769 tui_label.inc
     92 tui_lines.inc
    241 tui_lock.inc
    651 tui_matrix.inc
    295 tui_newsticker.inc
   3075 tui_object.inc
    621 tui_panel.inc
    517 tui_png.inc
    369 tui_progressbar.inc
    196 tui_progressbox.inc
   1762 tui_render.inc
   1940 tui_simpleauth.inc
     90 tui_spacers.inc
    124 tui_spinner.inc
    458 tui_splash.inc
    615 tui_ssh.inc
    423 tui_statusbar.inc
   1004 tui_terminal.inc
    209 tui_textbox.inc
   3877 tui_text.inc
    607 tui_typist.inc
    927 unicodecase.inc
   1484 url.inc
   4149 webserver.inc
   3068 X509.inc
   4726 zlib_deflate.inc
   2591 zlib_inflate.inc
 111916 total
    


hahah, as I will go on and on at length on the release website about, if Bjarn Himself had x86_64 assembler to deal with way back in the day, C never would have been invented in the first place. (Something about him saying "I created C so that me and my friends don't ever have to write in assembler ever again" comes to mind). Having written on 8 bit platforms, I wholeheartedly agree.

Case end point: don't be discouraged by the syscall interface, or debugging issues with linux, it is a pleasure to work with.

Smile
Post 30 Oct 2014, 03:45
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
tthsqe wrote:
Why don't you come over to windows? I think it is very comfortable. There is fdbg on this forum, and you have a suggestions for the debugger, I can probably work them into a modified version. Also, after about 10 years, 64 bit ollydbg is in the works...
I think EDB is much better than FDBG. Next best thing to Olly and IDA. You should check that one out, if you haven't.
Post 30 Oct 2014, 19:28
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
@redsock

god bless people like u and John for your kind effort. Keep it up.

But if u can feel the air, you'd come to the conclusion that many assembly programmers are actually avoiding Linux on the x86 platform. Most of those involved are actually hybrid C+asm programmers/experts or on to some other platform (android etc).

ASM programmers are the real deal when it comes down to the machines and architecture. They see what many HLL programmers don't see. So when most of them are silently avoiding something, new comers like myself should just join the wagon

But to be honest, it is not fair to compare Linux and Windows or Mac. But as a development platform for x86, Linux sucks. Even OEM manufacturers are having a hard time catching up with Linux mess. As i write this, my screen resolution is now in 640x400 mode. Some crappy Linux software just cant restore my default resolution upon exit. Imagine things like this happen when a user needs to push a critical button which is by now hidden somewhere down in the unseen video buffer!!

Laughing
Post 30 Oct 2014, 20:16
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
system error wrote:
Imagine things like this happen when a user needs to push a critical button which is by now hidden somewhere down in the unseen video buffer!!

Laughing


This situation is of course unpleasant, but in Linux you can at least drag any window by pressing and holding Alt when dragging with the mouse. In Windows such situation is really a disaster. Wink

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 30 Oct 2014, 20:38
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
JohnFound wrote:
system error wrote:
Imagine things like this happen when a user needs to push a critical button which is by now hidden somewhere down in the unseen video buffer!!

Laughing


This situation is of course unpleasant, but in Linux you can at least drag any window by pressing and holding Alt when dragging with the mouse. In Windows such situation is really a disaster. Wink


John, I'm not a Windows/Mac fan boy either. Don't get me wrong. But the bug I presented here wasn't because of the "crappy linux software" I mentioned. It's a perpetual bug in X-Window or x-org or whatever they call it that nobody seemed to care to fix. That means its a 20 years old bug! Exactly the reason why OEM like NVIDIA and others reluctant to get too much involved in Linux. Not to mention things like Photoshop or high-end graphical software like AutoCAD.
Post 30 Oct 2014, 20:58
View user's profile Send private message Reply with quote
HaHaAnonymous



Joined: 02 Dec 2012
Posts: 1180
Location: Unknown
HaHaAnonymous
[ Post removed by author. ]


Last edited by HaHaAnonymous on 28 Feb 2015, 18:02; edited 1 time in total
Post 04 Nov 2014, 00:54
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
system error
HaHaAnonymous wrote:
Quote:

Not to mention things like Photoshop or high-end graphical software like AutoCAD.

Proprietary software. They are simply not interested in making any software for Linux, they code primarily for rich people and companies.

system error, I used to think like you when I met Linux for the first time or without even knowing it... With a bit of patience and practice you will understand and LOVE it!

Or not... But that's rare.

It just needs a chance. Very Happy


yeah, you could be right. It's probably just me having a cultural shock. Beside, I don't use syscalls that much anyway. All I wanted to do was to try out 64-bit programming.
Post 11 Nov 2014, 16:44
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
JohnFound
Quote:
In Windows such situation is really a disaster.

What about Alt+Space, then M, and then the arrow keys?

_________________
Faith is a superposition of knowledge and fallacy
Post 11 Nov 2014, 21:38
View user's profile Send private message Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3502
Location: Bulgaria
JohnFound
l_inc wrote:
What about Alt+Space, then M, and then the arrow keys?


Well, AFAIK this works only for windows with window menu. The dialog and tool windows can't be moved this way. Also, I am not sure how far outside the screen the window can be moved this way.

_________________
Tox ID: 48C0321ADDB2FE5F644BB5E3D58B0D58C35E5BCBC81D7CD333633FEDF1047914A534256478D9
Post 11 Nov 2014, 21:53
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
JohnFound
Quote:
The dialog and tool windows can't be moved this way.

Both can, as long as they have the style WS_SYSMENU.
Quote:
I am not sure how far outside the screen the window can be moved this way.

This could be a problem indeed. I wrote a simple windows mover/resizer/styler/etc. to solve this kind of problems. Smile

_________________
Faith is a superposition of knowledge and fallacy
Post 11 Nov 2014, 22:09
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< 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 can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.