Issue 47459 - UNO broken ...
Summary: UNO broken ...
Status: CLOSED FIXED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: 680m92
Hardware: Other All
: P1 (highest) Trivial (vote)
Target Milestone: OOo 2.0
Assignee: chne
QA Contact: issues@udk
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-14 16:11 UTC by mmeeks
Modified: 2005-07-22 15:31 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description mmeeks 2005-04-14 16:11:18 UTC
It seems with gcc-3.3.3 ( and I assume any number of other compilers ) the cpp
bridge has been broken wrt. returning basic types.

The offending code is:

privateSnippetExecutorGeneral:
.LFBg:
    movl    %esp,%ecx
    pushl   %ebp              # proper stack frame needed for exception handling
.LCFIg0:
    movl    %esp,%ebp
.LCFIg1:
    subl    $0x8,%esp         # 64bit nRegReturn
    pushl   %ecx              # 32bit pCallStack
    pushl   %edx              # 32bit nVtableOffset
    pushl   %eax              # 32bit nFunctionIndex
    call    cpp_vtable_call
    movl    $123,%eax     # 64 bit nRegReturn, lower half
    leave
    ret

This is of course nonsense; it's calling a function:

extern "C" void cpp_vtable_call(
    int nFunctionIndex, int nVtableOffset, void** pCallStack,
    sal_Int64 nRegReturn )

If we add:
	nRegReturn = 3;

as the 1st line of this and examine the assembler we get:

.globl cpp_vtable_call
	.type	cpp_vtable_call, @function
cpp_vtable_call:
.LFB1172:
	pushl	%ebp
.LCFI6:
	movl	%esp, %ebp
.LCFI7:
	pushl	%edi
.LCFI8:
	pushl	%esi
.LCFI9:
	pushl	%ebx
.LCFI10:
	subl	$156, %esp
.LCFI11:
	call	__i686.get_pc_thunk.bx
	addl	$_GLOBAL_OFFSET_TABLE_, %ebx
	movl	8(%ebp), %edi
	movl	20(%ebp), %eax  # read (uninitialized) value of in nRegReturn
	movl	24(%ebp), %edx
	movl	%eax, -32(%ebp) # copy to scratch value
	movl	%edx, -28(%ebp)
	movl	$3, -32(%ebp)   # !!!!!!!!!

Without re-learning my rusty assembler; that's exactly what I'd expect to
happen; you can't have a function wandering around modifying it's parents stack
frame (surely).

Either way - this bit me because a11y was basically not working; dying in a call
returning a basic type.

testtool/unxlngi4.pro/lib/bridgetest_inprocess returns:

### bool does not match! failed
### char does not match! failed
### byte does not match! failed
### short does not match! failed
### unsigned short does not match! failed
### long does not match! failed
### unsigned long does not match! failed
### hyper does not match! failed
### unsigned hyper does not match! failed
### float does not match! failed
### double does not match! failed
### enum does not match! failed
struct comparison test failed

etc. - as one might expect.

The bug was introduced as this code was re-worked between milestone m80 and m81.
I'm reverting that change in my local build.
Comment 1 mmeeks 2005-04-14 16:16:23 UTC
> Without re-learning my rusty assembler; that's exactly what
> I'd expect to happen

so - it seems I am mad; the function ideally should be writing to there, but -
well, it just isn't so ...
Comment 2 kay.ramme 2005-04-14 16:44:00 UTC
Stephan, could this belong to you? Otherwise please forward to Daniel.
Comment 3 Stephan Bergmann 2005-04-14 18:22:48 UTC
accepted
Comment 4 Stephan Bergmann 2005-04-15 11:18:32 UTC
The original evaluation was wrong.  As DBO already found out overnight,
cpp_vtable_call erroneously depended on the compiler updating its in-parameter
nRegReturn, which the compiler is not required to do.  This did not show up with
GCC 3.4.1.

For testing, it should suffice to run the testtools bridgetest_inprocess---I
manually checked that it indeed executes all the modified functions in call.s.
Comment 5 mmeeks 2005-04-15 11:23:46 UTC
Thanks; cws sb32 now works perfectly for me with gcc 3.3.x :-)
Comment 6 Stephan Bergmann 2005-06-02 12:19:58 UTC
sb->cn: please verify

re-open issue and reassign to cn@openoffice.org
Comment 7 Stephan Bergmann 2005-06-02 12:20:04 UTC
reassign to cn@openoffice.org
Comment 8 Stephan Bergmann 2005-06-02 12:20:10 UTC
reset resolution to FIXED
Comment 9 chne 2005-06-02 12:49:59 UTC
verified in Linux and Windows in sb32
Comment 10 chne 2005-07-22 15:31:22 UTC
ok in src680_m119 => zu