Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Need help implementing a machine dependent function

0 views
Skip to first unread message

Jonathan Leighton

unread,
May 21, 2009, 1:17:10 AM5/21/09
to
I'm trying to add a machine dependent function to NSPR, but I'm having
some trouble understanding how the existing code translates from a
function like _PR_MD_FUNCTION() to the platform specific function
_MD_function(). In my case I'm using a function called
_PR_MD_SCTP_RECVMSG() in pr/src/pthreads/ptio.c and I want that to
translate to different MD_sctp_recvmsg() functions defined in the
various pr/src/md files. For example, on Solaris I'd expect
_PR_MD_SCTP_RECVMSG() to use the _MD_sctp_recvmsg() that I've added to
pr/src/md/unix/solaris.c.

I've tried to mimic the existing approach using several #define's and
extern function prototypes in various files, but I haven't been able to
make it work. As a fallback, I've simply specified an extern function
prototype for _PR_MD_SCTP_RECVMSG() in pr/include/private/primpl.h and
then defined _PR_MD_SCTP_RECVMSG() as extern in the various pr/src/md
files such as solaris.c. This works but it doesn't seem like the
"right" way to do it. I'd be grateful for any help explaining how to do
this correctly. Thanks very much.

- Jon

Nelson Bolyard

unread,
May 24, 2009, 6:47:01 PM5/24/09
to
Jonathan Leighton wrote, On 2009-05-20 22:17:
> I'm trying to add a machine dependent function to NSPR, but I'm having
> some trouble understanding how the existing code translates from a
> function like _PR_MD_FUNCTION() to the platform specific function
> _MD_function(). In my case I'm using a function called
> _PR_MD_SCTP_RECVMSG() in pr/src/pthreads/ptio.c and I want that to
> translate to different MD_sctp_recvmsg() functions defined in the various
> pr/src/md files. For example, on Solaris I'd expect
> _PR_MD_SCTP_RECVMSG() to use the _MD_sctp_recvmsg() that I've added to
> pr/src/md/unix/solaris.c.
>
> I've tried to mimic the existing approach using several #define's and
> extern function prototypes in various files, but I haven't been able to
> make it work.

Why not? In what manner does it fail?
We can't help you solve the problem if you don't describe it.

> As a fallback, I've simply specified an extern function prototype for
> _PR_MD_SCTP_RECVMSG() in pr/include/private/primpl.h and then defined
> _PR_MD_SCTP_RECVMSG() as extern in the various pr/src/md files such as
> solaris.c. This works but it doesn't seem like the "right" way to do it.

You're right. It's not.

Jon Leighton

unread,
May 25, 2009, 3:25:58 AM5/25/09
to
Nelson Bolyard wrote:
> Jonathan Leighton wrote, On 2009-05-20 22:17:
>> I'm trying to add a machine dependent function to NSPR, but I'm having
>> some trouble understanding how the existing code translates from a
>> function like _PR_MD_FUNCTION() to the platform specific function
>> _MD_function(). In my case I'm using a function called
>> _PR_MD_SCTP_RECVMSG() in pr/src/pthreads/ptio.c and I want that to
>> translate to different MD_sctp_recvmsg() functions defined in the various
>> pr/src/md files. For example, on Solaris I'd expect
>> _PR_MD_SCTP_RECVMSG() to use the _MD_sctp_recvmsg() that I've added to
>> pr/src/md/unix/solaris.c.
>>
>> I've tried to mimic the existing approach using several #define's and
>> extern function prototypes in various files, but I haven't been able to
>> make it work.
>
> Why not? In what manner does it fail?
> We can't help you solve the problem if you don't describe it.

Thanks for responding Nelson, and sorry I didn't provide more detail.
If I look at how _PR_MD_ACCEPT is implemented I see

in file primpl.h
extern PROsfd _PR_MD_ACCCEPT(...);
#define _PR_MD_ACCEPT _MD_ACCEPT

in file _win95.h
extern PROsfd _MD_Accept(...);
#define _MD_ACCEPT _MD_Accept

in file wsock95.c
PROsfd _MD_Accept(...) {...}

I tried to mimic this in Mac OS X with _PR_MD_SCTP_RECVMSG by adding the
following

in file primpl.h
extern PRInt32 _PR_MD_SCTP_RECVMSG(...);
#define _PR_MD_SCTP_RECVMSG _MD_SCTP_RECVMSG

in file _darwin.h
extern PRInt32 _MD_Sctp_Recvmsg(...);
#define _MD_SCTP_RECVMSG _MD_Sctp_Recvmsg

in file darwin.c
PRInt32 _MD_Sctp_Recvmsg(...) {...}

When I try to build I end up with a warning about an implicit definition
of _PR_MD_SCTP_RECVMSG in ptio.c (where I call the function), and the
build fails on nspr.dylib stating that _PR_MD_SCTP_RECV is an undefined
symbol. I can include the compiler output if that would be helpful.

- Jon

Nelson Bolyard

unread,
May 26, 2009, 12:53:51 PM5/26/09
to
Jon Leighton wrote, On 2009-05-25 00:25 PDT:

> I tried to mimic this in Mac OS X with _PR_MD_SCTP_RECVMSG by adding the
> following
>
> in file primpl.h
> extern PRInt32 _PR_MD_SCTP_RECVMSG(...);
> #define _PR_MD_SCTP_RECVMSG _MD_SCTP_RECVMSG

> When I try to build I end up with a warning about an implicit definition

> of _PR_MD_SCTP_RECVMSG in ptio.c (where I call the function), and the
> build fails on nspr.dylib stating that _PR_MD_SCTP_RECV is an undefined
> symbol. I can include the compiler output if that would be helpful.

The obvious implication of that warning/error is that one of the following
is true:
1) ptio.c did not include primpl.h or
2) the lines you added to primpl.h were inside a #if that was false, or
3) the copy of primpl.h that the compiler used did not contain your changes.

Did you do a full rebuild of NSPR after making your changes?
I'd suggest you start by doing a full rebuild.
Go into mozilla/nsprpub and find the directory in there that is created
by the build (name ends in .OBJ) and rm -rf it. Then rebuild.

If that doesn't fix it, then the next step is to look at the output of
the c pre-processor for ptio.c, and look for your changes. You won't see
the #defines, but you should see your other additions. If you don't then
you need to figure out why. The answer is likely #if or #ifdef.

--
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778

Jon Leighton

unread,
May 26, 2009, 5:05:09 PM5/26/09
to
Nelson Bolyard wrote:
> Jon Leighton wrote, On 2009-05-25 00:25 PDT:
>
>> I tried to mimic this in Mac OS X with _PR_MD_SCTP_RECVMSG by adding the
>> following
>>
>> in file primpl.h
>> extern PRInt32 _PR_MD_SCTP_RECVMSG(...);
>> #define _PR_MD_SCTP_RECVMSG _MD_SCTP_RECVMSG
>
>> When I try to build I end up with a warning about an implicit definition
>> of _PR_MD_SCTP_RECVMSG in ptio.c (where I call the function), and the
>> build fails on nspr.dylib stating that _PR_MD_SCTP_RECV is an undefined
>> symbol. I can include the compiler output if that would be helpful.
>
> The obvious implication of that warning/error is that one of the following
> is true:
> 1) ptio.c did not include primpl.h or
> 2) the lines you added to primpl.h were inside a #if that was false, or

Thank you! This was exactly the problem. I had mistakenly interpreted

#else /* defined(_PR_PTHREADS) */

to indicate the beginning of the _PR_PTHREADS=1 block, rather than the
end of that block. The code compiles and runs as expected now.

> 3) the copy of primpl.h that the compiler used did not contain your changes.
>
> Did you do a full rebuild of NSPR after making your changes?
> I'd suggest you start by doing a full rebuild.
> Go into mozilla/nsprpub and find the directory in there that is created
> by the build (name ends in .OBJ) and rm -rf it. Then rebuild.

I'm curious about the .OBJ files. I couldn't find either .OBJ or .obj
files anywhere in my builds for Darwin, FreeBSD, Solaris or Linux,
though I did find some objs.mk files. Are the .OBJ files generated on
all platforms?

0 new messages