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

Handle ARM relocations #121

Merged
merged 12 commits into from
Jul 16, 2018
Merged

Handle ARM relocations #121

merged 12 commits into from
Jul 16, 2018

Conversation

frederiksdun
Copy link
Contributor

This PR adds support to handle ARM's R_ARM_ABS32 relocation.
Fixes issue #86

@frederiksdun
Copy link
Contributor Author

Any hints why https://travis-ci.org/eliben/pyelftools/builds/170086267 failed, but 202 built?

@eliben
Copy link
Owner

eliben commented Oct 24, 2016

Looking at the error log it says:

Traceback (most recent call last):

  File "scripts/readelf.py", line 1229, in <module>

    main()

  File "scripts/readelf.py", line 1189, in main

    show_heading=not do_file_header)

  File "scripts/readelf.py", line 256, in display_section_headers

    nsec, section.name, describe_sh_type(section['sh_type'])))

  File "./elftools/elf/descriptions.py", line 58, in describe_sh_type

    elif x >= ENUM_SH_TYPE['SHT_LOOS'] and x < ENUM_SH_TYPE['SHT_GNU_versym']:

TypeError: unorderable types: str() >= int()

@@ aborting - 'scripts/readelf.py' returned '1'

You could try re-running it locally on Python 3.3+ to reproduce

@frederiksdun
Copy link
Contributor Author

@eliben I think the current problem is that exidx and unwind are defined as 0x70000001 which is used as key in a dict(). Is unwind a valid sh_type?

@eliben
Copy link
Owner

eliben commented Oct 25, 2016

Not sure if just kicking them out is the right approach. These enum values are in "processor-specific" space which means many of them collide between processors. I think if you look in enums.py you'll see a bunch of such duplicated values, no?

@frederiksdun
Copy link
Contributor Author

Yes I see duplicates in enum.py which cause problems in description.py.
Even PT_ARM_EXIDX and PT_ARM_UNWIND have the same value which would conflict if descriptions are machine aware.

Do we need the descriptions for UNWIND?

@eliben
Copy link
Owner

eliben commented Oct 26, 2016

I think this is also related to #71

eliben added a commit that referenced this pull request Oct 26, 2016
According to the ARM ABI it's an alias for PT_ARM_EXIDX; having them both in the
same enum value confuses parsing. Keeping EXIDX rather than UNWIND because
binutils seems to be using it.

Related to #121
@eliben
Copy link
Owner

eliben commented Oct 26, 2016

Ugh, this is a nasty issue. I think that for any given processor, all enums should be unique. I found that on ARM, EXIDX and UNWIND are synonyms (http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf) so I removed UNWIND.

However, across different processors it's valid to have duplications in that range (above 0x70000000). Here there's a deficiency in pyelftools parsing, in that it doesn't take the arch into account when parsing these fields. It should. This is also mentioned in #71.

@eliben
Copy link
Owner

eliben commented Oct 26, 2016

Presumably the test file you're adding hits this. Can you try to clean it up a bit (maybe just remove these segments) so it passes all tests? Then the PR can be pulled, since the parsing issue is unrelated

@frederiksdun
Copy link
Contributor Author

I rebased against master

@eliben
Copy link
Owner

eliben commented Oct 28, 2016

It seems like it's still failing on Travis for Python 3.4 and 3.5 -- maybe it's still the non-determinism?

@eliben
Copy link
Owner

eliben commented Oct 31, 2016

@frederiksdun I'll look into making the arch-specific field parsing work (as detailed here and in #71) -- it may unblock this PR. May take me a bit to find time for this, though

eliben added a commit that referenced this pull request Jan 15, 2018
This should address #71 and #121, hopefully
@eliben
Copy link
Owner

eliben commented Jan 15, 2018

A couple of recent commits made p_type and sh_type parsing dependent on e_machine, which should resolve the non-determinism issue in enums that was plaguing this.

I'll be happy to merge the PR if it's cleanly rebased on the latest master and all tests pass.

frederiksdun pushed a commit to frederiksdun/pyelftools that referenced this pull request Jul 16, 2018
This should address eliben#71 and eliben#121, hopefully
Generated on Ubuntu 14.04 using: arm-linux-gnueabi-gcc-4.7 -c -g -o reloc_armhf_gcc.o.elf hello.c
Generated on Ubuntu 14.04 using: arm-linux-gnueabihf-gcc-4.7 -c -g -o reloc_armhf_gcc.o.elf hello.c
@frederiksdun
Copy link
Contributor Author

I want to update some more details before merging

@frederiksdun
Copy link
Contributor Author

@eliben Feel free to merge

@eliben eliben merged commit ab76d5c into eliben:master Jul 16, 2018
vitalych pushed a commit to S2E/pyelftools that referenced this pull request Jan 28, 2020
* relocation: handle ARM binaries

* relocation: handle R_ARM_ABS32 for ARM machines

* testfiles: add reloc_arm_gcc.o.elf

Generated on Ubuntu 14.04 using: arm-linux-gnueabi-gcc-4.7 -c -g -o reloc_armhf_gcc.o.elf hello.c

* testfiles: add reloc_armhf_gcc.o.elf

Generated on Ubuntu 14.04 using: arm-linux-gnueabihf-gcc-4.7 -c -g -o reloc_armhf_gcc.o.elf hello.c

* readelf: print soft-float abi for ARM if EF_ARM_ABI_FLOAT_SOFT in flags

* readelf: print hard-float abi for ARM if EF_ARM_ABI_FLOAT_HARD in flags

* readelf: print BE8 info for armeb binaries

* testfiles: add simple_armhf_gcc.o.elf

    Generated on Ubuntu 14.04 using: arm-linux-gnueabihf-gcc-4.7  -g -o simple_armhf_gcc.o.elf hello.c

* elf: remove unwind from dicts and set ARM_EXIDX description

* testfiles: add  reloc_armsf_gcc.o.elf as soft float testcase taken from binutils 2.30

* testfiles: add reloc_armeb_gcc.o.elf as arm big endian testcase taken from binutils 2.30 testcase arm-be8

* readelf: print endian info LE8 if flag was set in header flags
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants