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

[M68K] Made instruction table static #1408

Merged
merged 1 commit into from
Mar 2, 2019
Merged

[M68K] Made instruction table static #1408

merged 1 commit into from
Mar 2, 2019

Conversation

emoon
Copy link
Contributor

@emoon emoon commented Mar 1, 2019

This solves the data race in #1397 by having the instruction table created upfront instead of the first time when trying to use the code which would generate a race condition in case of multiple threads trying to use the code at the same time.

The generation code has now been moved into to a separate tool called M68KInstructionTblGen.c I chose to keep the code still in C as if for some reason we want to generate the table in a dynamic fashion in the future is easier to move over the code to C again. Also I expect very few people will need to use this tool anyway.

@aquynh
Copy link
Collaborator

aquynh commented Mar 1, 2019

in all other archs, i use extension .inc for data files like your M68KInstructionTable.h. do you want to follow the same name scheme?

@aquynh
Copy link
Collaborator

aquynh commented Mar 1, 2019

regarding file arch/M68K/M68KInstructionTable.c, it is not compiled in the core, so we better move it elsewhere. one place is contrib/, you may move it there, put it under its own directory, and have Makefile for it at the same time.

@emoon
Copy link
Contributor Author

emoon commented Mar 1, 2019

Sure I can change the extension and move the file. Having a Makefile would be complex as it would need to support all possible compilers and pretty much no one will use this file.

@aquynh
Copy link
Collaborator

aquynh commented Mar 1, 2019

i suppose that the Makefile only needs to include that line you put at the top of M68KInstructionTblGen.c, no? why do we need to support all compilers?

@emoon
Copy link
Contributor Author

emoon commented Mar 1, 2019

I was thinking if the Makefile needed to support msvc etc

@aquynh
Copy link
Collaborator

aquynh commented Mar 1, 2019

oh no, this is only for developer/maintainer who needs to take care the code. there is no need to support MSVC, but only Linux/Mac is enough.

@emoon
Copy link
Contributor Author

emoon commented Mar 1, 2019

Ok cool! Thanks

@aquynh aquynh merged commit 309c07e into capstone-engine:next Mar 2, 2019
@aquynh
Copy link
Collaborator

aquynh commented Mar 2, 2019

merged, thanks!

@aquynh
Copy link
Collaborator

aquynh commented Mar 2, 2019

should we merge this into "v4" branch?

@tmfink
Copy link
Contributor

tmfink commented Mar 2, 2019

should we merge this into "v4" branch?

I would say yes. This only changes the internals (not affect on public interface) and fixes a bug, since according to https://www.capstone-engine.org/:

Thread-safe by design

Also, what's the difference between v4, master, and next branches? I'm a little confused by #1319. Thanks!

@tmfink
Copy link
Contributor

tmfink commented Mar 2, 2019

Also, what's the difference between v4, master, and next branches? I'm a little confused by #1319. Thanks!

Also, should there be a policy where we make bug PRs against the "next" branch first then cherry-pick into "master" (or whichever branch is appropriate)? This would prevent us from "missing" bug fixes in next and all future branches.

It looks like that is what we are doing here, but it may make sense to have that written in some "contributing" document.

@aquynh
Copy link
Collaborator

aquynh commented Mar 2, 2019

"v4" is a maintenance branch for 4.0.x version.

Actually we dont need to have "v4", but just "master" branch should play a role of stable & maintenance branch. But we discovered that "master" break compatibility of v4.0, i had to create "v4" branch for 4.0.x, which (soon will) revert the related commit to restore compatibility.

So far development for the v5 is in the "next" branch. People still do pull req for "master", which is pretty compatible with "next", and i cherry-pick for "next" manually.

When v5 is ready for release, we will merge "next" to "master".

Perhaps it will help if we make "v4" the default branch, to make it less confused for now?

@aquynh
Copy link
Collaborator

aquynh commented Mar 2, 2019

If a pull req is compatible with "v4", i still cherry-pick from "master" & "next". And vice versa.

aquynh pushed a commit that referenced this pull request Mar 2, 2019
@aquynh
Copy link
Collaborator

aquynh commented Mar 2, 2019

already cherry-picked this for "v4"

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

Successfully merging this pull request may close these issues.

3 participants