Sounds good to me! At the least it would be nice not to force u64 upon everyone.

Could you please provide an estimate of the efforts required to implement this functionality?
If this is going to help relocatable addresses handling, I wish to contribute to this issue. Could you please suggest a good starting point?
Thanks.

@vaibspider It's not a beginner task, and will require widespread changes to the read module. Unless someone has better ideas, the process will be:

• define a trait for operations that addresses must support (initially it won't need any operations, but we'll add them as required in the process of fixing everything)
• implement this trait for u64
• add the Reader::Address associated type
• figure out how Reader is going to convert an address-sized word into Reader::Address (this is harder than it was for offsets because the conversion may require some extra state)
• change Reader::read_address to return Reader::Address
• fix everything that uses Reader::read_address (which will require many flow-on changes).

I'm not sure if there is any way to break that last step into something more manageable.

Note that in theory relocatable addresses should already be possible. This issue would just make it nicer. So unless you're keen to do this, I would try to use the existing method. I'm currently updating my rewrite repository to check that this all works still.

Thanks for the insight! I tested reading a couple of relocatable object files, regenerating them (using object library) and linking them to get an executable. I noticed that object library worked fine with a relocatable object file but had issues with an executable file(couldn't reproduce all the contents and couldn't create an executable file). On the other hand, gimli seems to be working fine with executable files (I can read DWARF sections and modify them) but has issues when given a relocatable object file as input - (getting InvalidAttributeValue error). Could you please provide your input on this?
Thanks.

Replying in #482.