Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frontend has not been implemented yet to support va_arg at present. #4

Closed
cbakgly opened this issue Jul 2, 2013 · 9 comments
Closed
Labels

Comments

@cbakgly
Copy link
Contributor

cbakgly commented Jul 2, 2013

When you use clang to compile libm, you have to comment out 2 lines in semctl.c.
FYI.

@stopiccot
Copy link
Contributor

Just curious is it a clang problem or a crossbridge problem? Because as far as I know clang compiles FreeBSD 9 which sources are used in avm2_env

@cbakgly
Copy link
Contributor Author

cbakgly commented Jul 7, 2013

Really? Most of files under avm2_evn look unchanged comparing to master. Have you compared them to the freebsd version 9?

As an frontend, clang is different. It means you can not just switch to clang to make crossbridge work exactly as before unless you implement must-have parts. va_args is one of parts waiting to be added in.
I am going to add it after I get a clear picture of it. Also welcome anyone to make it come true. :)

@stopiccot
Copy link
Contributor

I've found interesting statement in emscripten FAQ. They say that problem is caused by LE32 clang frontend and everything is OK with X86 frontend. Is crossbridge forced to use LE32 frontend?

@stopiccot
Copy link
Contributor

I had investigated a bit further. And here are my thoughts what is the source of problem.
Error statement is: "cannot compile this aggregate va_arg expression yet"
After searching a bit I found that this error is raised in method AggExprEmitter::VisitVAArgExpr() (llvm-3.2/tools/clang/lib/GodeGen/CGExprAgg.cpp) As we see error occurs when method CGM.getTypes().getABIInfo().EmitVAArg() in method CodeGenFunction::EmitVAArg() (llvm-3.2/tools/clang/lib/CodeGen/CGCall.cpp) returns 0. ABI is initialized in method CodeGenModule::getTargetCodeGenInfo() (llvm-3.2/tools/clang/lib/GodeGen/TargetInfo.cpp)
For unknown for clang custom "avm2" architecture clang intializes DefaultTargetCodeGenInfo that stores DefaultABIInfo inside. DefaultABIInfo::EmitVAArg() is not implemented and just returns 0. So it seems to be not a clang problem. At least not a problem that should be fixed by clang team. We need to implement AVM2ABIInfo that implements EmitVAArg() method

@cbakgly
Copy link
Contributor Author

cbakgly commented Jul 8, 2013

Sorry for the misleading title. :'(
What I was trying to say was this part had not been added to clang yet. I never indicated it's a clang issue.

@stopiccot
Copy link
Contributor

Oh, now I get it. But how it worked for gcc? Can we just use X86ABI? Initiallly I thought that flascc just takes LLVM created for generic X86 target and than converts it to AVM2 assembler, but now I'm not so sure. Also as far as I understand EmitVAArg just fetches value from valist according to abi convention. But where values are stored to valist according to that convention?

@cbakgly
Copy link
Contributor Author

cbakgly commented Jul 10, 2013

OK, I see you just copied a few lines as what I did. Though they are different under hood, but I guess X86ABI may work for this case, would you like to commit a more complete version by borrowing some code of X86_32?

@stopiccot
Copy link
Contributor

Yep, I just looked through different implementations of EmitVAArgs for different platforms and extracted lines that seem to be common for all implementations. Yes, suggested implementation lacks alignment support. But I simply don't know how it should be done for avm2 or will X86_32 code work for avm2. So this implementation is just a first iteration that will allow code to compile, and probably to work.

@cbakgly
Copy link
Contributor Author

cbakgly commented Jul 11, 2013

Ok, just let it fly over the compilation and be fixed in future.

@cbakgly cbakgly closed this as completed Jul 11, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants