it looks like with the change to the API to just return st_value, few bots broke, Subham ?

Can we use print raw values option for now ?

Shouldn't nm just print the raw value stored in the symbol table like what readelf does ?

Ping ?

I believe more tools like llvm-readobj also would need to parse the attribute structure, and even lld.

Updated patch with reverting the previous change.

Can you please merge the change ?

https://reviews.llvm.org/D31500

Thanks Peter, I will revise the lld test and recommit the change.

Check for section permissions to account for test cases that rely on the behavior.

The changes are causing a problem as tests in lld have been written with the assumption that objdump will be able to dump data inside of a text section. I am hence uploading a new patch that checks for section permissions as well. Please let me know how you want to go about it ?

Thanks Tim for the detailed review.

Address comments from Tim. I will make the AArch64 changes as a separate commit.

Does AARCH64 use Mapping symbols anytime ? I havent seen GCC doing that.

Ping ?

Update with comments from Tim and address the issue that he mentioned.

I was discussing with Colin L and found a way to handle your case. Will post a patch soon.

Though, The testcase that you have mentioned is a genuine test and GCC supports it!.

I see what you are saying.

Updated with review comments from Tim.

It looks like gcc doesnot purely go by whether section has data or not. It also checks for section permissions.

I totally forgot about your comment, I will respond to you with a testcase shortly.

Ah ok. Thanks for the info. If the input is 'C', the extent to which a non allocatable section that can contain data and code mixed is really a corner case, unless the author does inline assembly ?

When I checked with GCC (Using tests) the behavior seems to be non allocatable sections do not have mapping symbols.

I was trying to debug a problem with the usage of FileOutputBuffer where the memory contents are not being synced to disk. I traced every call in FileOutputBuffer and none of the calls return an error, but the file is not synced. This happens on windows systems with FAST IO enabled. Resizing the underlying file makes the problem disappear.

r_offset is being modeled as per the ELF spec IMO and looks correct. GNU objdump does show relocations when there are relocation sections, that point to the section that needs relocation.

How are symbols resolved when there are multiple --start-group and --end-group options currently ? Which symbol is picked when there is a unresolved symbol from the second group ?

I am trying to say without --start-group and --end-group, the linker would have produced an unresolved symbol.

Thanks Ruiu, Bigcheese. It would become confusing for the user when migrating from the GNU linker.

Any other comments ?, If not I will go ahead and commit this change and continue getting the Atom model for ELF

Thanks for the info, LGTM.