Assembly files translated for GCC syntax (no need for NASM)

[Goran Devic]

Hi Oleg,

Wow - that's a considerable work to change every line of the ASM file
:) Did you compile with old and new files and compare the binaries?
They should match exactly, otherwise we have a problem in translation
by hand.

In the meantime, we got it to compile under 2.6 cleanly, and NASM was
also successfully used. What we can do is to ship both files, and have
your one default, so the people dont have to install NASM. I would
still like to keep original files just for the cross-reference, for
people like me who are not familiar with GCC asm syntax to learn,
should another change be necessary. I know that means keeping two files
in sync, but beats the heck of googling for gcc syntax for those few of
us :)

Quick poll: What's the group preference for NASM vs. GCC asm?

Thanks!
- Goran

On Mon, 20 Dec 2004 23:10:04 +0300, Oleg Khudyakov
<prc...@potrebitel.ru> wrote:
> > I noticed you did not join the group, it would be beneficial if you
> > do, so we can discuss all the issues there and avoid any redundant
> > work.
>
> I have joined group using prc...@mail.ru e-mail address.
> At that time there was only one message in group. But their quantity
> quickly grows :-)
>
> > If you can send me your new ASM files by email, I think it is a
> > valuable contribution that you did by rewriting the syntax so we
dont
> > have to use NASM. I do like NASM syntax better, it is cleaner and
more
> > like MASM for what its worth, but there is definitely a benefit of
> > _not_ having to install NASM, and thanks for your work on it. Let
me
> > review it and then add it to the next official release. If you dont
> > object, I will also add your name to the list of contributors :)
>
> Certainly I do not object. It would be quite good :-) But check up a
code on
> presence of mistakes, please. They could appear during change of
syntax.
> Though I tried to translate a code one for one only changing sintax.
I love
> NASM syntax more too, but for compiling of kernel modules in 2.6
files .c
> or .s are required.
>
> I create the module with the following makefile
>
> obj-m := linice.o
> all:
> $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
>
> And it creates linice.ko module.
>
> Files endasm.s and i386.s included.
> --
> WBR,
> Oleg Khudyakov
>
>

[rezn]

i think that its a nice piece of work you have done porting linice to
gas, but for my money i'd rather have a single set of sources.
personally, i too prefer nasm (its better!) and dont think its too big
a deal to make it a dependency. perhaps a binary distribution of nasm
compiled objects could be included in case someone cant get nasm to
compile. i'm not sure what kind of compile time dependencies the nasm
code has wrt the target kernel, though, so maybe this isnt an option.

either way, my vote is to choose one or the other (nasm or gas) and
stick to it.

[prcoder]

I love NASM syntax more, but the majority of open source products uses
GCC asm and it became more standard.
Thats why I used it. Another reason is that no more _shipped tricks
wilie compiling the module.

Right before I used new keyboard patches from Peter, but at loading
time have faced a new problem. Similarly that it is connected to that
in my system is used udevfs...

SYSTEM.MAP: /boot/System.map
Reading kernel locations from System.map file:
switch_to = 02104774
handle_scancode = 021E0FEC
handle_kbd_event = 021E127E
sys_call_table = 022E73C0
module_list = 022EAE30
insmod -f linice.ko ice_debug_level=1 kbd=35525246 scan=35524588
pmodule=36613680 sys=36598720 switchto=34621300
Info: /root/linice/bin-2.6-new/driver.c,140: init_module
Info: /root/linice/bin-2.6-new/driver.c,141: kbd 021E127E
Info: /root/linice/bin-2.6-new/driver.c,142: scan 021E0FEC
Info: /root/linice/bin-2.6-new/driver.c,143: pmodule 022EAE30
Info: /root/linice/bin-2.6-new/driver.c,144: sys 022E73C0
Info: /root/linice/bin-2.6-new/driver.c,145: switchto 02104774
Info: /root/linice/bin-2.6-new/keyboard.c,429: KeyboardHook()
Info: /root/linice/bin-2.6-new/keyboard.c,446: Call to handle_scancode
at 021E12F4
ERROR: Failed to register character device
Info: /root/linice/bin-2.6-new/keyboard.c,476: KeyboardUnhook()
Error (256) loading linice module!

Some about my system:
Distr: ASPLinux 10 beta 1170 (based on Fedora Core 2 and hardly
patched)
Kernel 2.6.9-1.640asptpc (Built by myself from ASP sources).
Somebody has ideas how it can be corrected?

[Goran Devic]

1) It seems like ice_register_chrdev() in driver.c:170 failed to
register /dev/ice device. Make sure that device file is not present
when loading linice. The other problem might be with the iceface.c
(kernel-dependent interface code):

int ice_register_chrdev(char *pDevice)
{
return( register_chrdev(0, pDevice, &ice_fops) );
}

Perhaps ice_fops is not defined correctly for that kernel version?

2) So you recompiled the kernel and removed "static" for those
functions that need export in order to get those symbols to show up in
your System.map file?

3) What did you mean by the following:

"Another reason is that no more _shipped tricks
wilie compiling the module."

?

Thanks

[Goran Devic]

I dont think you _need_to_ compile NASM. A binary NASM version is
already included with the linice distribution, for both libc5 and 6. It
should work pretty much with any kernel version. Let's hold on this for
now, until the critical work with 2.6 is not done.

[prcoder]

I mean that new module-compiling makefiles ("obj-m += hello.o") uses
only .c and .s source files
for generating .ko module and it is necessary to use tricks like this
for building modules with NASM
sources. But I can be mistaken...

cp linice_kernel.o linice_kernel.o.temp
touch linice_kernel.c
make -C /usr/src/linux-`uname -r` SUBDIRS=$PWD modules
mv linice_kernel.o.temp linice_kernel.o
make -C /usr/src/linux-`uname -r` SUBDIRS=$PWD modules

[prcoder]

1) Device file /dev/ice is not present when i loading linice.
register_chrdev(0, pDevice, &ice_fops) returns -EBUSY (Major number
busy error)

2) regiser_cherdev is in my System.map file and it is likely that it
work

[geocar]

Goran Devic wrote:
> Quick poll: What's the group preference for NASM vs. GCC asm?

AT&T assembly has a very important thing going for it:

People unfamiliar with the architecture can still follow it.

* registers _always_ preceded with "%"
* the "right side argument" is _always_ the target
* values _always_ preceded with "$"
* indirect jumps hilighted with "*"
etc

[Mario Schallner]

if you ask :)

then I prefer intel rather than AT&T just because started assembly under
"a different OS".

I think intel syntax is more readable - as an opposite to the advantage
you see.

Indexing is displayed more rational:
80483e5: 8d b3 18 ff ff ff lea 0xffffff18(%ebx),%esi

80483e5: 8d b3 18 ff ff ff lea esi,[ebx-232]

which imho helps more than $,%,*. also i think people not knowing what a
"eax" is will probably not really be interrested to look into a
disassembly or am I wrong. In general this is of course right and I like
strong syntax rules as well! But I think it is not so much an argument
then readability? :)

i can also say:

* the "left side argument" is _always_ the target
* values _always_ preceded with "0x"
* indirect addressing (jumps, movs, ...) hilighted with "$"

only registers are not explicitly marked, the rest is also with intel syntax.

regards, my 2 cents

[Goran Devic]

Are there any Perl or other translators that could translate NASM to
gasm syntax?

[geocar]

Your disassembler is broken. There's no reason it couldn't have said:

80483e5: bd b3 18 ff ff ff lea -232(%ebx), %esi

The left-side, right-side argument only works for AT&T asm anyway
because Intel assembly encodings simply aren't appropriate for other
architectures.

And in Intel assembly, values aren't always preceded with 0x; it'd
probably be better to say that values don't have square-brackets "near
them" - defining near them to be on the same side as the comma.

Indirect addresses aren't _always_ marked with a $-sign either; many
Intel books use the jmp near [...] syntax.

Now as to "readability" - I can't argue that. I used to think Intel
assembly was the better bet when I was used to it. I'm not used to it
anymore- so I simply can't say that I find it "more or less" readable.

But I am faced with "other systems" asm recently, and I find
remembering simple rules about AT&T assembly to be the single biggest
reason I still have any hair left...