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

Calculating size of function #54

Open
0152la opened this issue Dec 6, 2021 · 4 comments
Open

Calculating size of function #54

0152la opened this issue Dec 6, 2021 · 4 comments
Assignees

Comments

@0152la
Copy link
Contributor

0152la commented Dec 6, 2021

Suppose we have a function definition, in either C or assembly. Is it possible to calculate the size of such a function (presumably in byes) at compile time? One potential solution would be to have the functions whose sizes we want to calculate in a separate file, compile it, and perform the computation based on ELF data, but are there maybe easier solutions?

@ltratt
Copy link
Collaborator

ltratt commented Dec 6, 2021

@vext01 might have some ELF-ish thoughts about this?

@jacobbramley
Copy link
Contributor

A typical method (e.g. used by clang and others) is to define a (local) symbol at the end of the function and set .size based on arithmetic. For example:

    .globl  func
    .p2align        2
    .type   func,@function
func:
    ...
    ret
.Lfunc_end0:
    .size    func, .Lfunc_end0-func

It might not be feasible to read that from source — I've never tried — but for assembly functions you can define a global symbol (instead of the local .Lfunc_end0) or perhaps calculate the size and store it as some other global constant.

@0152la
Copy link
Contributor Author

0152la commented Jan 13, 2022

An approach of doing this was implemented in #55. Do we still want to keep this issue for potential future improvements to the current implementation?

@jacobbramley
Copy link
Contributor

In principle we could do better — making it a static constant with a relocation — but whether or not that is achievable is unclear. It's probably a low priority concern, anyway.

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

3 participants