Prev: Can we get a definitive on what iodelay is needed?
Next: asm + memory in windows
From: chrisbdaemon on 18 Jun 2008 23:45
Hey, I too just started "The Art of Assembly Language" and I was
planning on doing my work in a Linux virtual machine through VMWare
Fusion on my MacBook. The version of Linux I'm using is BackTrack 3
(the only linux vm I had on hand) and its running Linux 2.6.21.5.

So, I was able to run the commands listed in the book just fine, got
the executables in the right spot, added the environment variables to
my path, etc. But when I tried to compile that HelloWorld program for
the first time it looked like it worked alright but when trying to run
it, here is what I see:

bt hla# ./hw
Killed

If it matters, heres the output from the command I ran to compile it:

HLA (High Level Assembler) Parser
use '-license' to view license information
Version Version 1.99 build 12922 (prototype)
-t active
File: hw.hla
Output Path: ""
Language Level: high

Compiling "hw.hla" to "hw.o"
Compilation complete, 14838 lines, 0.066 seconds, 224818 lines/
second
Using flat assembler version C1.66
3 passes, 1499 bytes.
HLA (High Level Assembler)
Use '-license' to see licensing information.
Version Version 1.99 build 12922 (prototype)
ELF output
OBJ output using internal FASM back-end
-test active

HLA Lib Path: /usr/hla/hlalib/hlalib.a
HLA include path: /usr/hla/include
HLA temp path:
Files:
1: hw.hla

Compiling 'hw.hla' to 'hw.o'
using command line:
[hlaparse -level=high -v -sf -celf -test "hw.hla"]

----------------------
----------------------
Linking via [ld -o "hw" "hw.o" "/usr/hla/hlalib/hlalib.a"]
From: santosh on 19 Jun 2008 02:08
chrisbdaemon wrote:

> Hey, I too just started "The Art of Assembly Language" and I was
> planning on doing my work in a Linux virtual machine through VMWare
> Fusion on my MacBook. The version of Linux I'm using is BackTrack 3
> (the only linux vm I had on hand) and its running Linux 2.6.21.5.
>
> So, I was able to run the commands listed in the book just fine, got
> the executables in the right spot, added the environment variables to
> my path, etc. But when I tried to compile that HelloWorld program for
> the first time it looked like it worked alright but when trying to run
> it, here is what I see:
>
> bt hla# ./hw
> Killed

Run the program under a debugger like GDB or ALD and find out where
exactly it is getting terminated. BTW, the "Killed" message looks
unusual to me. Usually you get something like "segmentation fault".

<snip>

From: Herbert Kleebauer on 19 Jun 2008 03:57
chrisbdaemon wrote:

Sorry can't help with your problem (but maybe it is the same
problem we discussed a few month ago here, see below), but this
is real funny:



> my path, etc. But when I tried to compile that HelloWorld program for
^^^^^^^^^^^^^^^^^^

> Compilation complete, 14838 lines, 0.066 seconds, 224818 lines/
^^^^^^^^^^^ ^^^^^^^^^^^^^

That's what I call assembly programming: 14838 lines for a HelloWorld
program.



Newsgroups: alt.lang.asm
Date: Wed, 16 Apr 2008 10:49:25 +0200
Local: Wed, Apr 16 2008 4:49 am
Subject: Re: Why is my nasm program killing itself?


Didn't any experiments, but if I understand you and Chuck correctly, the
situation is as following:

The Author of the linker is a former DOS com programmer and wanted to
avoid any unnecessary byte in the executable. Therefore, if there is data
segment at all (and you always should have one, because, as I understand
you, there are kernel versions which have a problem when the last segment
isn't write able) and this data segment has a file size of 0 (only a .bss
section but no .data section), he didn't align this block of zero bytes
on a 4 byte boundary. But the loader still insist that this not existing
bytes have to be aligned at a four byte boundary. Don't know which
one is the bad boy, the linker or the loader (the elf specification
should tell us, but I'm to lazy).

But obviously the loader doesn't complain if the start address of this
zero byte block is outside the file limits (as long as it is aligned)
or my hand written elf header would and the code generated by your patch
program could crash.
From: Frank Kotler on 19 Jun 2008 07:00
chrisbdaemon wrote:

....
> bt hla# ./hw
> Killed

As Santosh says, "segfault" is more common if your program is hosed.
"Killed" is usually from the loader. (possibly different in a vm???)
This means that gdb/ald aren't going to give you any useful information. :(

....
> OBJ output using internal FASM back-end

The internal Fasm output (in HLA 1.99) in Linux is gefukt. Try adding
the "-xg" switch to use (G)as instead. My recollection is that this
problem results in "segfault", not "killed", though.

There's *another* issue with at least one version of ld -
2.17.50.0.17.20070615 (not a good day at the skunkworks). This is the
alignment issue Herbert mentions, which does result in "killed"... but
which "shouldn't" happen with HLA (since it does have a ".data"
section). Besides, your Linux version is new enough so it "shouldn't"
have this ld version...

See if just "-xg" will fix you up. If not, we may need to discuss ld
versions, and/or output from objdump and/or readelf...

Good luck,
Frank

From: Herbert Kleebauer on 19 Jun 2008 07:55
Herbert Kleebauer wrote:
>
> chrisbdaemon wrote:
>
> is real funny:
>
> > my path, etc. But when I tried to compile that HelloWorld program for
> ^^^^^^^^^^^^^^^^^^
>
> > Compilation complete, 14838 lines, 0.066 seconds, 224818 lines/
> ^^^^^^^^^^^ ^^^^^^^^^^^^^
>
> That's what I call assembly programming: 14838 lines for a HelloWorld
> program.


Ok, here a real "Hello world" Linux assembly program (164 byte):


;===========================================================================

seg32
@=$08048000
code_offset=@@
code_addr:

;--------------------------- ELF header -----------------------------------

00000000: 08048000: 464c457f 00010101
00000008: 08048008: 00000000 00000000
00000010: 08048010: 00030002 00000001
00000018: 08048018: 08048074 00000034
00000020: 08048020: 00000000 00000000
00000028: 08048028: 00200034 00000002
00000030: 08048030: 00000000 dc.l $464c457f,$00010101,0,0,$00030002,1,main,$34,0,0,$00200034,2,0
00000034: 08048034: 00000001 00000000
0000003c: 0804803c: 08048000 08048000
00000044: 08048044: 000000a2 000000a2
0000004c: 0804804c: 00000005 00001000 dc.l 1,code_offset,code_addr,code_addr,code_filez,code_memsz,5,4096
00000054: 08048054: 00000001 000000a4
0000005c: 0804805c: 080490a4 080490a4
00000064: 08048064: 00000000 00000000
0000006c: 0804806c: 00000006 00001000 dc.l 1,data_offset,data_addr,data_addr,data_filez,data_memsz,6,4096

;--------------------------- code ------------------------------------------

main:
00000074: 08048074: bb 00000001 move.l #1,r3 ; stdout
00000079: 08048079: b9 08048093 move.l #text,r2 ; pointer to text
0000007e: 0804807e: ba 0000000f move.l #textl,r1 ; length of text
00000083: 08048083: b8 00000004 move.l #4,r0 ; write
00000088: 08048088: cd 80 trap #$80 ; call kernel
0000008a: 0804808a: 31 db eor.l r3,r3 ; return code
0000008c: 0804808c: b8 00000001 move.l #1,r0 ; exit
00000091: 08048091: cd 80 trap #$80

;--------------------------- constant data ---------------------------------

00000093: 08048093: 0a 0a 48 65 6c 6c
00000099: 08048099: 6f 20 77 6f 72 6c
0000009f: 0804809f: 64 0a 0a text: dc.b 10,10,"Hello world",10,10
textl=@-text

;---------------------------------------------------------------------------

code_filez=@@-code_offset
code_memsz= @-code_addr
000000a2: 080480a2: 00 00 even 4
@=(@+4095)/4096*4096+(@@\4096)
data_offset=@@
data_addr:

;--------------------------- initialized data ------------------------------

;var1: dc.l 1
;var2: dc.l 11

;--------------------------- uninitialized data ----------------------------

;buf: blk.b 4

;---------------------------------------------------------------------------

data_filez=@@-data_offset
data_memsz= @-data_addr

;===========================================================================
 |  Next  |  Last
Pages: 1 2 3
Prev: Can we get a definitive on what iodelay is needed?
Next: asm + memory in windows