Hello Frank,
Thank you for your message !
>> That is strange indeed!
That's it !
>> I first introduced "res" (local - on the stack) and printed it. Then introduced "temp" and sprinted to it, and did the
>> ms_message. Still "works for me". I have not yet tried the switch.
I tried the code, I have already posted; just like the following
; Assembler code
cpu 586
bits 32
;'''''''''''''''''''''''''''''''''''''''''''''''''
; exported entry point
;'''''''''''''''''''''''''''''''''''''''''''''''''
global decode_asm:function ; declare it as a function
section .data
section .bss
section .text
decode_asm:
; setup the return value of the function
mov eax, dword 0
ret
// C - Code
void libmsg722_init(void)
{
char temp[200];
int res = 0;
ms_filter_register(&ms_g722_dec_desc);
ms_message("G.722 decoder registered\n"); // first output
ms_filter_register(&ms_g722_enc_desc);
ms_message("G.722 encoder registered\n"); // second output
// This call functions correctly
decode_asm(NULL, NULL, 0,0,0);
// That is ok too
ms_message("calling decode_asm %i\n", decode_asm(NULL, NULL, 0, 0, 0));
// ************* And this produces a crash including a segmentation fault *********************
res = decode_asm(NULL, NULL, 0, 0, 0);
memset(temp, 0, 200);
sprintf(temp, "result = %i\n", res);
ms_message(temp);
// ******************************************************
// ************* And this produces a crash including a segmentation fault too*********************
switch(decode_asm(NULL, NULL, 0, 0, 0))
{
case 0:
default:
// do something with the return code
break;
}
// ******************************************************
}
The problem is the same as I described in my last posting from November 28, 2011, 12:16:26 pm.
>> There is something I just noticed, that I should have commented on earlier. Way back on Nov. 12, you posted some asm
>> code that did a get_got_ebx. If we alter ebx in a function that returns to C, we need to restore its original value
>> (push/pop). I don't think you're doing that currently, so I don't think it's an issue, but when/if we get past the current
>> segfault and you return to similar code, you'll want to do that (also esi and edi need to be preserved, if we alter 'em).
That's a good advice and I have to test my code for that kind of problem. Thank you !
But the code I have posted to that forum (shown above) does not contain get_got_ebx
or something like that because I have no variables. Look at the code shown above to be
sure.
>> Getting back to the present, I think your asm is fine. In the code you post above, you've got "cpu" and "586" on separate
>> lines... well, I guess it depends on how I display it - now it looks fine. Wouldn't assemble that way anyway. I think your
>> asm is fine.
Hope so..
>> Odd that you're showing the address of decode_asm as being on the stack, and I'm showing it as in the 0x40000000
>> block, where I'd expect a shared library to be located. I don't know why that is, but it might be a "clue"(?).
You know, I'm running that code using VMWare workstation 7.x. Maybe, the address range could differ to that, what
it would be using the original Linux system !?
>> C will sometimes put things in read-only memory. For example, printf("hello world");, the "hello world" is in read-only
>> ("const") memory. But "res" ought to be allright, either on the stack or "global" (I think).
That is one of my real problems to get the right return value. That doesen't work correctly on my system.
If I have a variable to store the return value of decode_asm there, a segmentation fault follows instantly.
That's one of my problems. I don't know what is the reason that there is a different behavior on different
Linux systems. (Look at the problem to store the return value using a local variable !)
But it's like yesterday: We have 22:59 pm and I'm tired and I have to go to bed. Sorry for that behavior !
I'm just a human..
Again: Thank you for your help !
Zasti
