Thank you for your reply, I will test your suggestion tomorrow.
test_nua.exe passed correctly with that darcs branch:
http://people.collabora.co.uk/~alban/darcs/sofia-sip-alban-linkage/
(for viewing patchs:
http://monkey.collabora.co.uk/sofia-sip-alban-linkage/ )
The first patch fixs the bug in mmp files, and the second is a
hack to avoid the problem (not to be merged!).
--
Alban
Le Tue, 26 Feb 2008 20:56:32 +0200,
"Pekka Pessi" <[EMAIL PROTECTED]> a écrit :
> 2008/2/26, Alban Crequy <[EMAIL PROTECTED]>:
> > > I think the static variable is initialized before the DLL
> > > linkage is complete.
> >
> > It makes sense. Do you think this problem occurs only on the
> > simulator, or also on the device ? (I only tested the simulator.)
>
> I have no idea, but I think the DLL linking code is same on both. I
> recall that Martti had to fix similar stuff within Sofia SIP DLL
> (initializing pthread_mutex_t structs, if I recall correctly).
>
> > > The additional complication is that Sofia SIP DLL exports
> > > an array or struct but Symbian (and Windows) DLL linkage does not
> > > support them, it supports just pointers. The __declspec() magic
> > > is implemented badly in the Symbian compilers (not to speak about
> > > Windows), so they may end up of using the pointer to the pointer
> > > to the array/struct where they should just use pointer to the
> > > array/struct.
>
> > I don't understand this additional complication. Do you have a link
> > explaining this limitation on pointers and structures ? I don't
> > think this complication happened in my tests until now.
>
> Basically, we say we export
>
> __declspec(export) int array[3];
>
> and application says it imports
>
> __declspec(import) int array[3];
>
> What the application actually gets, is a variable of type
>
> int (*_array)[3];
>
> which is for most purposes identical to
>
> int **_array;
>
> When we initialize a variable with value of array with definition like
>
> int *pointer = array;
>
> the Symbian/Windows linker can not initialize the data segment
> correctly, but the C runtime should call some generated code that
> fetches the value from *array and stores it to the variable. I suspect
> that the runtime fails to do so, or does it in incorrect order, or the
> C compiler simply does not generate necessary code (as it is not
> needed on Unix systems).
>
> > > It seems to me that Martti just avoids static initialization with
> > > pointers from DLL.
>
> > Do you mean in other programs using the sofia-sip DLLs ? The test
> > programs seems to use static initialization.
>
> I failed to find one with quick grep. I meant something like
>
> static tagi_t tags[] = {{ NUTAG_ANY() } ... };
>
> but now understand that you meant that also this
>
> tagi_t tags[] = {{ NUTAG_ANY() } ... };
>
> breaks on Symbian.
>
> > > > But this pattern is used a lot in sofia-sip. I don't know
> > > > whether changing this pattern is the right thing to do. Maybe
> > > > it is a bug in the compiler, epoc, or whatever and we should
> > > > fix the real bug instead. (?)
> > > >
> > > > For example, see:
> > > > ./libsofia-sip-ua/nua/test_nua_params.c line 59 that uses
> > > > NUTAG_ANY, which is a macro expanding to symbol nutag_any from
> > > > the dll.
> > >
> > > I think this particular example should work without problems
> > > (assuming, of course, that you have fixed the
> > > IN_LIBSOFIA_SIP_UA).
>
> > I have run a binary search to find symbols that break the linkage
> > (e.g. symbols that are used with the problematic pattern). In
> > addition to macros SOFIAPUBVAR/SOFIAPUBFUN that extends to the
> > wrong __declspec(), I added my own macros that extends to the right
> > __declspec(). I did not just fix the macro because it would be
> > difficult to find every occurance of the problematic pattern in one
> > step. So I can replace each problematic pattern with the pattern
> > that works, step by step (as I have done in the example [1]).
> >
> > And when I use __declspec() correctly on nutag_any, it crashs
> > unless I also use the following patch:
> >
> > ----->8-----------
> > sofia-sip-1.12.8/libsofia-sip-ua/nua/test_nua_params.c
> > @@ -56,10 +56,14 @@
> > tag_typedef_t tag_b = STRTAG_TYPEDEF(b);
> > #define TAG_B(s) tag_b, tag_str_v((s))
> >
> > - tagi_t filter[2] = {{ NUTAG_ANY() }, { TAG_END() }};
> > + tagi_t filter[2] = {{ TAG_END() }, { TAG_END() }};
> >
> > tagi_t *lst, *result;
> >
> > + filter[0].t_tag = nutag_any;
> > + filter[0].t_value = (tag_value_t)0;
> > +
> > lst = tl_list(TAG_A("X"),
> > TAG_SKIP(2),
> > NUTAG_URL((void *)"urn:foo"),
> > ----->8-----------
> >
> > The patch is a hack, but show that when nutag_any is used to
> > initialize a variable before the DLL linkage is complete, it crashs.
>
> > So far, I also changed the variables _proxy_challenger and
> > _registrar_challenger from ./libsofia-sip-ua/nua/test_proxy.c with
> > a similar patch than above.
> >
> >
> > > Or
> > > then the __declspec() magic breaks in even worse way on Symbian
> > > than on Windows.
> >
> >
> > I don't think the problem on nutag_any is worse than the problem in
> > [1]. I think it is the same problem.
> >
> > [1] http://discussion.forum.nokia.com/forum/showthread.php?t=127457
>
> You are probably correct.
>
> > Any suggestions to fix the problem ?
>
> Check that you are linking correct runtime for your compiler.
>
> Could you generate asm with your GCC from a C file with function using
> non-zero array initializer like
>
> #include <sofia-sip/su_tag.h>
>
> tagi_t *tester(void)
> {
> tagi_t filter[2] = {{ NUTAG_ANY() }, { TAG_END() }};
> return tl_adup(NULL, filter);
> }
>
> and post it? I wonder if the generated code does memcpy from data
> segment, for instance, or initializes the array explicitly, and if
> there is some extra code that initializes the data segment in
> C++-manner, and if so, how it is supposed to be called (you might need
> to call such code explicitly).
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
