Many warnings of the implicit conversion happen when building elfconv.

[yomaytk]

When we build elfconv with the command ninja, many warnings of the implicit conversion on remill occur as follows.

In file included from .../elfconv/backend/remill/lib/Arch/AArch64/Runtime/Instructions.cpp:25:
.../elfconv/backend/remill/include/remill/Arch/Runtime/Operators.h:472:1: warning: implicit conversion changes signedness: 'uint32_t' (aka 'unsigned int') to 'int' [-Wsign-conversion]
MAKE_READMVI(S, 32, int32_t, 32)

These warnings seem not to lead to execution errors for now, but these are annoying and may cause fatal execution errors.

[XueSongTap]

Can I work on this？

[yomaytk]

Yes, of course. There are a lot of warnings, but it would help if you could just reduce some of them :)

[XueSongTap]

I’ve successfully reproduced the warnings that occur during the ninja build of elfconv, such as the signedness conversion warning in Operators.h:472 (uint32_t to int) and the precision loss warnings in CALL_RET.cpp (uint64_t to addr_t). These warnings are clearly visible in the build logs, and I can provide full reproduction steps and logs if needed.
While working on fixing these reproduced warnings, I noticed that elfconv/backend/remill might not be in sync with the upstream lifting-bits/remill. To ensure the fix is applied correctly, I’d like to clarify:

1. Is elfconv/backend/remill a direct fork or copy of lifting-bits/remill? If so, which specific version or commit (e.g., commit hash) is it based on?
2. If I modify elfconv/backend/remill directly (e.g., changing addr_t from unsigned int to uint64_t), could it impact other parts of elfconv? Or would it be better to submit the fixes to lifting-bits/remill upstream and then update elfconv’s dependency?
3. Does elfconv have custom modifications to remill that prevent it from syncing directly with the upstream version?

My initial plan is to address these reproduced warnings locally in elfconv/backend/remill (e.g., by adjusting type definitions) and test the build and functionality afterward. If it works, I’d submit a PR. Before proceeding, I’d like to confirm if this is the right approach to avoid potential conflicts or duplicated effort.
Thanks for any advice or guidance!

[yomaytk]

Thank you for working.

Is elfconv/backend/remill a direct fork or copy of lifting-bits/remill? If so, which specific version or commit (e.g., commit hash) is it based on?

Yes, elfconv/backend/remill is a direct copy, but I have not traced the upstream of remill, so I cannot know the correct dependent version of remill. However, the date of initial commit of elfconv is Nov 15, 2023 (23aec15), so I think elfconv is based on any of these commits(lifting-bits/remill@17cff6b, lifting-bits/remill@0183248, lifting-bits/remill@7182636).

1. If I modify elfconv/backend/remill directly (e.g., changing addr_t from unsigned int to uint64_t), could it impact other parts of elfconv? Or would it be better to submit the fixes to lifting-bits/remill upstream and then update elfconv’s dependency?
2. Does elfconv have custom modifications to remill that prevent it from syncing directly with the upstream version?

addr_t is used in many parts of both x86-64 and aarch64, so changing addr_t may impact other parts. However, elfconv is mainly focusing on 64-bit architecture. For example, elfconv doesn't build the target of aarch32 as follows.

elfconv/backend/remill/CMakeLists.txt

Line 218 in abc4cee

# "REMILL_BUILD_SEMANTICS_DIR_AARCH32=\"${REMILL_BUILD_SEMANTICS_DIR_AARCH32}\""

Thus, changing addr_t from unsigned int to uint64_t seems to be good if the warnings are deleted. If you submit PR, I will check it and I can discuss it with you even if it impacts other parts.
elfconv/backend/remill has been modified in many parts, and I have not traced the upstream of remill yet because remill is not being developed actively, so I don't care about the fixes to the original remill. It is enough to fix only elfconv/backend/remill.

My initial plan is to address these reproduced warnings locally in elfconv/backend/remill (e.g., by adjusting type definitions) and test the build and functionality afterward. If it works, I’d submit a PR. Before proceeding, I’d like to confirm if this is the right approach to avoid potential conflicts or duplicated effort.
Thanks for any advice or guidance!

That's great. if you are ready, please submit PR!