Prev: Can we get a definitive on what iodelay is needed?
Next: asm + memory in windows
From: Frank Kotler on 19 Jun 2008 08:51
Herbert Kleebauer wrote:
> 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):

Yeah, but where's the Structured Exception Handling? Can't have a
HelloWorld without SEH! :)

(come to think of it, if an HLA program *did* segfault, it would be
reported as "HLA error nnn" - evidence that Chris' "killed" is coming
from the loader...)

Best,
Frank
From: Herbert Kleebauer on 19 Jun 2008 12:11
Frank Kotler wrote:
> Herbert Kleebauer 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):
>
> Yeah, but where's the Structured Exception Handling? Can't have a
> HelloWorld without SEH! :)

But is the HLA lib a source code library or how else is it
possible that 14838/224818 lines have to be compiled for a simple
HelloWorld program? (Maybe RosAsm is the new back end assembler for
HLA).
From: chrisbdaemon on 19 Jun 2008 12:34
> 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...

-xg worked like a charm. I appreciate the quick-fix but would someone
mind explaining why it worked with gas and not fasm? One of the
reasons I'm trying to learn assembly is a better understanding of low-
level things like this.
From: santosh on 19 Jun 2008 12:57
Herbert Kleebauer wrote:

> Frank Kotler wrote:
>> Herbert Kleebauer 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):
>>
>> Yeah, but where's the Structured Exception Handling? Can't have a
>> HelloWorld without SEH! :)
>
> But is the HLA lib a source code library or how else is it
> possible that 14838/224818 lines have to be compiled for a simple
> HelloWorld program? (Maybe RosAsm is the new back end assembler for
> HLA).

No. Only the header files for the HLA standard library are included in
source form in HLA programs. The library itself is in object code form
and is linked with a HLA program by the system linker.

From: Frank Kotler on 19 Jun 2008 16:38
chrisbdaemon wrote:

....
> -xg worked like a charm. I appreciate the quick-fix but would someone
> mind explaining why it worked with gas and not fasm?

The problem is not with Fasm, per se, but with the "internal Fasm" code
in HLA. We all make bugs from time to time - unfortunately, *this* bug
made it into the "frozen" HLA 1.99.

> One of the
> reasons I'm trying to learn assembly is a better understanding of low-
> level things like this.

Okay!!! You may ("will", I think) find that HLA is not ideal for
examining the low-level nitty-gritty. You may also want to ditch the
emulator/vm and work with your "real" OS... maybe even ditch the OS and
work with "real" hardware (no idea how this is done on a Mac, even if
it's "MacIntel"... if not... less than no idea...). But your setup gives
you something to start with, at least.

Herbert posted a "minimal" elf executable. You noticed(?) a bunch of
numbers in front, before the executable code starts. This is the
executable header - any executable more complicated than a dos .com file
has one. "Normally", if we don't provide it, it is created by the
linker... from a linkable object file. This, too, includes information
about how and where the parts fit together, besides the executable code.
The "low level" way to examine this would be to just look at the bytes -
in hex, usually - but the "objdump" utility displays it in more
readable(?) form.

This is part of the output from "objdump -x HelloWorldWithVar.o" - just
adds a numeric variable to "helloworld" and prints "the answer is 5"
(or "the answer is segfault" in some cases)...


HelloWorldWithVar.o: file format elf32-i386
HelloWorldWithVar.o
architecture: i386, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000000 00000000 00000000 00000034 2**4
ALLOC, READONLY, CODE
1 .data 00000020 00000000 00000000 00000034 2**4
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .bss 00000000 00000000 00000000 00000054 2**4
ALLOC
3 .text 00000058 00000000 00000000 00000054 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .text 0000000a 00000000 00000000 000000ac 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
5 .data 0000000c 00000000 00000000 000000b6 2**4
CONTENTS, ALLOC, LOAD, DATA
6 .text 00000069 00000000 00000000 000000c2 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
7 .text 00000000 00000000 00000000 0000012b 2**4
ALLOC, READONLY, CODE


Notice that some ".text" sections (this is the "historical" name for an
executable section - damned if I know why they didn't call it "code"!)
have fewer "attributes" than others. The "internal Fasm" section of HLA
has told the linker - for some ".text" sections but not others(!) - to
allocate memory for us, protect it as "readonly" and "executable"... but
don't "LOAD" anything because we have no "CONTENTS". Amazingly, earlier
versions of ld got a working executable out of this mess, but somewhere
along the line, ld got "fussier" (in the interest of security, I
imagine). If you examine the resulting executable, you'll see blocks of
zeros where some of the code should be. I assume this bug is in
"cfasm.c"... possibly "codegen.c" (don't think so).

This may not be the same thing that's killing your code. IIRC, the guy
who reported this had HelloWorld working, only HelloWorldWithVar was
failing... and the message was "segfault", not "killed". I'm guessing
we're in the right ballpark, though...

If you want to get deeper into this - maybe even "fix" HLA - we can. Not
strictly speaking "assembly language", but it involves the nitty-gritty
details that many of us are interested in. Personally, I mostly "let ld
do it" and don't allocate many braincells to this "OS cruft", but it
*is* a vital part of an executable file (or linkable object file)...

As a start, you could do "objdump -x" (and/or other switches) to your
two .o files - made with "internal Fasm" and with Gas - and see what you
see...

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