Multithreaded asm program terminates with a negative number

[climber.cui]

Hi all,
I have built a compiler that generates multi-threaded x86 assembly
code, by calling Pthreads functions. The generated assembly code works
fine, except it always terminate with some large negative number. And
this number does not seem to correspond any thread id( of created
thread).
I am tracing the program execution with gdb (gun debugger), and get
this:

1412 ret
(gdb) s
0xb7e5687c in __libc_start_main () from /lib/libc.so.6
(gdb) s
Single stepping until exit from function __libc_start_main, which has
no line number information.
-1079169088
Program exited with code 044.
(gdb) s
The program is not being run.
---------------------------------------------------------------------------
The number -1079169088, is the unexpected number i was talking about.
I first thought this is normal. However, I simulated the compiler
generated code in C, and translate C to assembly code using gcc -S,
then execution terminates fine, no negative number is produced upon
program termination:

720 ret
(gdb) s
0xb7e2187c in __libc_start_main () from /lib/libc.so.6
(gdb) s
Single stepping until exit from function __libc_start_main, which has
no line number information.

Program exited normally.
(gdb) s
The program is not being run.

Now i would like to remove that unexpected number output. Any ideas?
Thanks.

tony

[NathanCBaker]

On Dec 12, 8:44 am, climber.cui <spamt...@crayne.org> wrote:
> Hi all,
>    I have built a compiler that generates multi-threaded x86 assembly
> code, by calling Pthreads functions. The generated assembly code works
> fine, except it always terminate with some large negative number. And
> this number does not seem to correspond any thread id( of created
> thread).
>   I am tracing the program execution with gdb (gun debugger), and get
> this:
>
> 1412            ret
> (gdb) s
> 0xb7e5687c in __libc_start_main () from /lib/libc.so.6
> (gdb) s
> Single stepping until exit from function __libc_start_main, which has
> no line number information.
> -1079169088
> Program exited with code 044.
> (gdb) s
> The program is not being run.
>

The 'exit code' of 044 will map to one of the error conditions listed
here:

http://www.gnu.org/software/libtool/manual/libc/Error-Codes.html

You will need to examine the assignments in "errno.h" to discover
which condition your assembly code is triggering.

Nathan.

[Tim Roberts]

climber.cui <spam...@crayne.org> wrote:
>
> I have built a compiler that generates multi-threaded x86 assembly
>code, by calling Pthreads functions. The generated assembly code works
>fine, except it always terminate with some large negative number. And
>this number does not seem to correspond any thread id( of created
>thread).

Are you leaving some predictable value in "eax" when your main function
returns?
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

[climber.cui]

> Are you leaving some predictable value in "eax" when your main function
> returns?
> --

> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.

I do not know what value is stored in 'eax' when the main function
returns. It could contain some value needed for computation before the
program terminates. (Do you mean that I probably should return some
value to 'eax', like zero?)
perhaps, this could do the job:
movl $0, %eax

tony

[Tim Roberts]

climber.cui <spam...@crayne.org> wrote:
>
>> Are you leaving some predictable value in "eax" when your main function
>> returns?
>

>I do not know what value is stored in 'eax' when the main function
>returns. It could contain some value needed for computation before the
>program terminates. (Do you mean that I probably should return some
>value to 'eax', like zero?)
>perhaps, this could do the job:
> movl $0, %eax

Well, of course. "main" is a function, and the return value of the program
is the value returned from the "main" function. If you expect some
predictable value to be returned from the program, then you have to return
that value in eax.

[H. Peter Anvin]

Tim Roberts wrote:
> Well, of course. "main" is a function, and the return value of the program
> is the value returned from the "main" function. If you expect some
> predictable value to be returned from the program, then you have to return
> that value in eax.

Specifically, the C runtime code invokes main() in a manner equivalent
to the code:

exit(main(argc, argv, envp));

... so the return value from main() is passed to exit().

-hpa