Closed Bug 620888 Opened 14 years ago Closed 13 years ago

ReadParam(msg, iter, uint32) is extracted to ReadParam(msg, iter, size_t/intptr_t) on Windows x86

Categories

(Core :: IPC, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla5

People

(Reporter: m_kato, Assigned: m_kato)

References

Details

Attachments

(1 file, 2 obsolete files)

ReadParam(msg, iter, uint32) is extraced to ReadParam(msg, iter, size_t/intptr_t) on Windows x86.  if uint32, we should not use size_t due to compatiblity of 32bit <-> 64bit IPC and reduction of IPC message size.


- Disassembled code on the latest nightly

0:044> x xul!*nsACString*::Read
66065a37 xul!IPC::ParamTraits<nsACString_internal>::Read (class IPC::Message *, void **, class nsACString_internal *)

0:044> u 66065a37
xul!IPC::ParamTraits<nsACString_internal>::Read:
66065a37 55              push    ebp
66065a38 8bec            mov     ebp,esp
66065a3a 51              push    ecx
66065a3b 56              push    esi
66065a3c 8b7508          mov     esi,dword ptr [ebp+8]
66065a3f 8d450b          lea     eax,[ebp+0Bh]
66065a42 50              push    eax
66065a43 ff750c          push    dword ptr [ebp+0Ch]
66065a46 83c604          add     esi,4
66065a49 56              push    esi
66065a4a e83026ebff      call    xul!Pickle::ReadBool (65f1807f)
66065a4f 84c0            test    al,al
66065a51 7449            je      xul!IPC::ParamTraits<nsACString_internal>::Read+0x65 (66065a9c)
66065a53 807d0b00        cmp     byte ptr [ebp+0Bh],0
66065a57 740e            je      xul!IPC::ParamTraits<nsACString_internal>::Read+0x30 (66065a67)
66065a59 6a01            push    1
66065a5b ff7510          push    dword ptr [ebp+10h]
66065a5e e86a26f3ff      call    xul!nsACString_internal::SetIsVoid (65f980cd)
66065a63 b001            mov     al,1
66065a65 eb37            jmp     xul!IPC::ParamTraits<nsACString_internal>::Read+0x67 (66065a9e)
66065a67 8d4508          lea     eax,[ebp+8]
66065a6a 50              push    eax
66065a6b ff750c          push    dword ptr [ebp+0Ch]
66065a6e 56              push    esi
66065a6f e82b25ebff      call    xul!Pickle::ReadIntPtr (65f17f9f)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ <-- HERE
66065a74 84c0            test    al,al
66065a76 7424            je      xul!IPC::ParamTraits<nsACString_internal>::Read+0x65 (66065a9c)
66065a78 ff7508          push    dword ptr [ebp+8]
66065a7b 8d45fc          lea     eax,[ebp-4]
66065a7e 50              push    eax
66065a7f ff750c          push    dword ptr [ebp+0Ch]
66065a82 56              push    esi
66065a83 e88d24ebff      call    xul!Pickle::ReadBytes (65f17f15)
66065a88 84c0            test    al,al
66065a8a 7410            je      xul!IPC::ParamTraits<nsACString_internal>::Read+0x65 (66065a9c)
66065a8c ff7508          push    dword ptr [ebp+8]
66065a8f 8b55fc          mov     edx,dword ptr [ebp-4]
66065a92 8b4d10          mov     ecx,dword ptr [ebp+10h]
66065a95 e83666aaff      call    xul!nsACString_internal::Assign (65b0c0d0)
66065a9a ebc7            jmp     xul!IPC::ParamTraits<nsACString_internal>::Read+0x2c (66065a63)
66065a9c 32c0            xor     al,al
66065a9e 5e              pop     esi
66065a9f c9              leave
66065aa0 c3              ret
Summary: ReadParam(msg, iter, uint32) is extraced to ReadParam(msg, iter, size_t/intptr_t) on Windows x86 → ReadParam(msg, iter, uint32) is extracted to ReadParam(msg, iter, size_t/intptr_t) on Windows x86
I am having difficulty imagining a hybrid 32/64 bit IPC setup.  When we build, don't we build the browser and plugin-container in the same manner?
(In reply to comment #1)
> I am having difficulty imagining a hybrid 32/64 bit IPC setup.  When we build,
> don't we build the browser and plugin-container in the same manner?

64bit Windows build env builds 64-bit binary only.  But IPC protocol should be considered that 64bit process talks with 32bit process.  Example, on Mac OS X 64 bit firefox can talk with 32-bit plugin-container.

I am analyzing and testing 32bit process and 64bit process built from same source code.
Attached patch fix v1 (obsolete) — Splinter Review
Assignee: nobody → m_kato
Attached patch fix v1.1 (obsolete) — Splinter Review
Attachment #499247 - Attachment is obsolete: true
Attachment #499612 - Flags: review?(jones.chris.g)
Status: NEW → ASSIGNED
>+#if !(defined(OS_MACOSX) || defined(OS_WIN) || (defined(CHROMIUM_MOZILLA_BUILD) && defined(OS_LINUX) defined(ARCH_CPU_64_BITS)))

This line is certainly not going to work as intened; look at the last two conditions.
Attachment #499612 - Attachment is obsolete: true
Attachment #499612 - Flags: review?(jones.chris.g)
Attached patch fixSplinter Review
Attachment #507805 - Flags: review?(jones.chris.g)
Comment on attachment 507805 [details] [diff] [review]
fix

We already overcame this obstacle with mixed-architecture mac OOPP.

  bool WriteIntPtr(intptr_t value) {
    // Always written as a 64-bit value since the size for this type can
    // differ between architectures.
    return WriteInt64(int64(value));
  }

// Always written as a 64-bit value since the size for this type can
// differ between architectures.
bool Pickle::ReadIntPtr(void** iter, intptr_t* result) const {
Attachment #507805 - Flags: review?(jones.chris.g) → review-
On Mac OS X, (In reply to comment #7)
> Comment on attachment 507805 [details] [diff] [review]
> fix
> 
> We already overcame this obstacle with mixed-architecture mac OOPP.

Chris, Do you say that ReadParam(aMsg, aIter, PRUint32) should be extracted to ReadIntPtr()?

struct ParamTraits<size_t> is never defined on Mac OS X.  So this issue isn't on Mac OS X.  On Mac OS X both 32bit and 64bit is extracted it to ReadUInt32().

xul!IPC::ParamTraits<nsACString_internal>::Read() calls ReadParam(aMsg, aIter, PRUint32)) in http://mxr.mozilla.org/mozilla-central/source/ipc/glue/IPCMessageUtils.h?mark=228-229#228.  So on Mac OS X (that can use OOPP) extracts it to ParamTraits<PRUint32>::Read(m, iter, PRUint32).   But on Windows x86, it extracts to ParamTraits<void *>::Read(m, iter, void*)....
On Windows x86, struct ParamTraits<uint32> uses ReadSize()
Oh, I misunderstood what you were trying to fix.

Yeah, saving a few bytes here sounds fine.
Comment on attachment 507805 [details] [diff] [review]
fix

r=me assuming it's green on tryserver ;).  This code is very fragile.
Attachment #507805 - Flags: review- → review+
Comment on attachment 507805 [details] [diff] [review]
fix

pass tests on try server
Attachment #507805 - Flags: approval2.0?
Attachment #507805 - Flags: approval2.0? → approval2.0-
Depends on: post2.0
http://hg.mozilla.org/mozilla-central/rev/302723303f42
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
No longer depends on: post2.0
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: