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

Split ARCH_SOURCES_DIR into target and platform ones #7537

Closed
janvorli opened this issue Mar 2, 2017 · 3 comments
Closed

Split ARCH_SOURCES_DIR into target and platform ones #7537

janvorli opened this issue Mar 2, 2017 · 3 comments
Labels
area-Infrastructure-coreclr backlog-cleanup-candidate An inactive issue that has been marked for automated closure. enhancement Product code improvement that does NOT require public API changes/additions help wanted [up-for-grabs] Good issue for external contributors no-recent-activity

Comments

@janvorli
Copy link
Member

janvorli commented Mar 2, 2017

We have a single ARCH_SOURCES_DIR defined based on the platform we are building for. However, when crossbuilding tools that run on one platform, but target another one (e.g. crossgen running on x86 and generating ARM32 code), we need to use two different architecture sources dirs. One for files that are used to generate code for the target architecture and the other for files that run on the platform where the tool is executed.
That means that all .asm (.S) files belong to the second category, while some .cpp files in the target spefic folders belong to one and some to the other. For example, the excepamd64.cpp belong to the second category and jitinterfaceamd64.cpp to the first one.

@janvorli
Copy link
Member Author

janvorli commented Mar 2, 2017

CC: @hseok-oh

@msftgits msftgits transferred this issue from dotnet/coreclr Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
Copy link
Contributor

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

@dotnet-policy-service dotnet-policy-service bot added backlog-cleanup-candidate An inactive issue that has been marked for automated closure. no-recent-activity labels May 12, 2024
Copy link
Contributor

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.

@dotnet-policy-service dotnet-policy-service bot removed this from the Future milestone May 26, 2024
Infrastructure Backlog automation moved this from Future to Closed May 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Infrastructure-coreclr backlog-cleanup-candidate An inactive issue that has been marked for automated closure. enhancement Product code improvement that does NOT require public API changes/additions help wanted [up-for-grabs] Good issue for external contributors no-recent-activity
Projects
Status: Done
Development

No branches or pull requests

2 participants