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

alias attribute is handled incorrectly (and incompletely) #17

Open
stephenrkell opened this issue Sep 5, 2014 · 0 comments
Open

alias attribute is handled incorrectly (and incompletely) #17

stephenrkell opened this issue Sep 5, 2014 · 0 comments

Comments

@stephenrkell
Copy link
Contributor

I recently stumbled on the following code in cabs2cil that handles (non-variadic) function aliases.

  let rt, formals, isva, _ = splitFunctionType vtype in
  if isva then E.s (error "%a: alias unsupported with varargs."
                      d_loc !currentLoc);
  let args = Util.list_map 
               (fun (n,_,_) -> A.VARIABLE n)
               (argsToList formals) in
  let call = A.CALL (A.VARIABLE othername, args) in
  let stmt = if isVoidType rt then A.COMPUTATION(call, loc)
                              else A.RETURN(call, loc)
  in
  let body = { A.blabels = []; A.battrs = []; A.bstmts = [stmt] } in
  let fdef = A.FUNDEF (sname, body, loc, loc) in
  ignore (doDecl true fdef);
  (* get the new function *)
  let v,_ = try lookupGlobalVar thisname
            with Not_found -> E.s (bug "error in doDecl") in
  v.vattr <- dropAttribute "alias" v.vattr

It seems to define the alias by creating a fresh function which calls the aliased function. This is semantically wrong because the two functions' addresses should be equal. Also, it doesn't handle varargs functions, and aliases of variables are not implemented at all. (I am currently trying to compile eglibc with CIL, and it uses aliases a lot.)

The only sane fix seems to be to change the data model, so that every GVar has a list of aliases, each with their own attributes. This would seem to require an API-breaking change -- or is there a better way?

At least the following would then have to happen. Aliases all get declared when the global is declared. Lookups by name must resolve aliases when appropriate. Each alias probably ought to have its own location, although that could probably be finessed away if it were too great a change.

I am adding this to my internal to-do queue, but would welcome suggestions for alternative ways to deal with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant