We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello, I am getting the following error when I am trying to link my project:
*** ERROR L103: EXTERNAL ATTRIBUT DO NOT MATCH PUBLIC SYMBOL: ?_s_denormalise?BYTE MODULE: .\rsa_modexp.obj (RSA_MODEXP)
What can be the possible causes of this error? I looked at the discussion at http://www.keil.com/support/docs/1742.htm
But there is a difference between the situation illustrated there and mine. First of all, my symbol is not a variable but a segment name for the function s_denormalise written in assembly language. Secondly, I am not declaring this function as extern. I have this .A51 source file containing the implementation of s_denormalise and I have a header file(.h) containing the prototype declaration of s_denormalise. I am including this header file in my rsa_modexp.c file and using the function. Then how does this explanation accounts for my case?
If there can be any other cause for this error, please let me know.
Thanks and Regards, venkat.
"the thing that the 'C' is expecting does not match the thing that assembler is providing"
You said you got the code from Philips (NXP).
Did they actually say that it is for use with Keil tools?
The internal Calling conventions, parameter passing, naming, etc are all entirely Compiler-specific - so if it doesn't specifically say that it'll work with Keil, you should assume that it Won't.
See: www.8052.com/.../read.phtml (which also relates to Philips code)
Thanks Neil, for a prompt reply..
Now I realize the 'extern' thing there. What you said is absolutely right. The parameter calling conventions are not the same for Keil's C51 and the assembly code I have. I observed that another function which has only three parameters did not have this problem(C51 passes a maximum of three parameters on registers and others in fixed memory locations). Now it is clear that only functions whose parameters are being passed in memory locations are causing the problem(s_denormalise for instance).
I did as you suggested - I produced the SRC file using SRC directive and here is what I got in the SRC file correponding to my C file:
EXTRN CODE (_s_denormalise) EXTRN XDATA (?_s_denormalise?BYTE)
Clearly, the memory locations in which C51 is passing parameters are in XDATA. And in my SDENORM.A51(which contains the implementation of s_denormalise)the following is the declaration of the segment:
NAME SDENORM ?PR?_s_denormalise?SDENORM SEGMENT CODE ?DT?_s_denormalise?SDENORM SEGMENT DATA OVERLAYABLE PUBLIC ?_s_denormalise?BYTE RSEG ?DT?_s_denormalise?SDENORM ?_s_denormalise?BYTE: Rn_addr: DS 1 Rn_length: DS 1 Nn_addr: DS 2 d_addr: DS 2 d_length: DS 1
My suspicion is that "?DT?s_denormalise?SDENORM" indicates that segment(and hence the parameters stored in it) are present in DATA memory which is conflicting with XDATA as declared in my C file. If can change the assembly file by replacing all 'DT's by 'XD's and DATA by XDATA and all mov instructions by movx instructions will I be able to generate compatibility between my C file and the assembly code? It is a bit lengthy process to change all mov instructions to movx since the file is large. So, I seek your advice before I embark on it.
Thanks again, venkat.
"will I be able to generate compatibility between my C file and the assembly code?"
Again, did the code claim compatibility with Keil C51?
If it didn't, there's probably no point trying to make it so - you'll just end up fixing this problem and then running into another! :-( Your best bet then would probably be to create a "wrapper" between the assembler and the 'C' to convert the calling conventions.
If the code does claim compatibility with Keil C51, be sure to also check what version!
Then you will need to read http://www.keil.com/support/man/docs/c51/c51_ap_ctoasm.htm
If you're lucky, this will just be a matter of changing the Memory Model for the C51 compiler, and rebuilding...
The code did not claim any compatibility with C51. So, I guess i will have to tweak a little bit and try it out. As you said, writing a wrapper seems to be best solution. Thank you for your kind advice, it has been very helpful for us.
"... writing a wrapper ..."
A common model, I might add, but just a bit less so on '51 platforms.
Hello all, I am indeed lucky!.. I just had to change the memory model for this specific function declaration from Large to Small.
venkat.
why are you even in the totally wasteful LARGE model which is solely provided for those that do not feel they have the energy to take make the effort to write efficient code.
Erik
I am an undergraduate student doing this as part of a course. I understand that using Large model is wasteful. I am learning my lessons though, everyday and I learned from this discussion too... :)
venkat