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

Add Tensilica Xtensa processor support #5442

Closed

Conversation

austinc3030
Copy link
Contributor

@austinc3030 austinc3030 commented Jun 11, 2023

This PR is aimed at adding support for Tensillica's Xtensa processor/architecture to ghidra. This PR is an updated duplicate of #1407. I am creating this PR as the existing PR's submitter appears to no longer maintain their branch. I intend to continue maintaining this PR until:

  • merged
  • the original submitter reappears
  • advised otherwise

An updated sample elf can be found at https://dl.espressif.com/dl/esp32_rom.elf. Additional samples will be provided promptly upon request.

at = nsa(as);
}

# NSAU - Normalization Shift Amount Unsigned, pg. 462. (Count leading zeros)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lzcount is a new built-in pcode that might simplify this assuming it is Count leading zeros

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in 29bf647.

This definitely cleans up the de-compiler output for the NSAU instruction. I was unaware of this new pcode.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also looks like you can replace the NSA implementation nsa() with lzcount(~as) (and delete pcodeop nsa in the other file)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in afa0ff6. I saw this but wasn't sure myself whether this would be applicable. Thank you!


# RFDD - Return from Debug and Dispatch, pg. 484.
:rfdd is op2 = 0b1111 & op1 = 0b0001 & ar = 0b1110 & (as = 0b0000 | as = 0b0001) & at = 0b0001 & op0 = 0 {
rfdd();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all these return from might help disassembler and produce better decompilation with return something. right now they'd just fall through, but they should have some sort of flow

might try something like this for all of these:

-    rfdd();
+    local tmp:4 = rfdd();
+    return [tmp];

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed in c5e8f01. Thank you!

@mumbel
Copy link
Contributor

mumbel commented Jun 16, 2023

I honestly cant remember the state of this file, but I have a pattern file

this would be data/patterns/xtensa_patterns.xml
https://gist.github.com/mumbel/f7a81b2f416a8cb4bb489ace1f458a97

and then data/patterns/patternconstraints.xml

<patternconstraints>
  <language id="Xtensa:LE:32:default">
  	<compiler id="default">
  	  <patternfile>xtensa_patterns.xml</patternfile>
  	</compiler>
  </language>
</patternconstraints>

@austinc3030
Copy link
Contributor Author

I honestly cant remember the state of this file, but I have a pattern file

this would be data/patterns/xtensa_patterns.xml https://gist.github.com/mumbel/f7a81b2f416a8cb4bb489ace1f458a97

and then data/patterns/patternconstraints.xml

<patternconstraints>
  <language id="Xtensa:LE:32:default">
  	<compiler id="default">
  	  <patternfile>xtensa_patterns.xml</patternfile>
  	</compiler>
  </language>
</patternconstraints>

Added in 563efe9.

@redfast00
Copy link
Contributor

@austinc3030 Aside from the relocations (which are not needed for embedded targets, like the ESP32), is there any work that still needs to happen on this PR? I'd really like to see this as a part of Ghidra, so I'll try to help out if needed.

@austinc3030
Copy link
Contributor Author

austinc3030 commented Jul 12, 2023

@austinc3030 Aside from the relocations (which are not needed for embedded targets, like the ESP32), is there any work that still needs to happen on this PR? I'd really like to see this as a part of Ghidra, so I'll try to help out if needed.

I don't think so? I have been using this pretty successfully against some esp32 firmware images. I appreciate any help or suggestions you may have!

@k0rd
Copy link

k0rd commented Jul 12, 2023

thank you for this work - it works well for me!

@redfast00
Copy link
Contributor

@austinc3030 Aside from the relocations (which are not needed for embedded targets, like the ESP32), is there any work that still needs to happen on this PR? I'd really like to see this as a part of Ghidra, so I'll try to help out if needed.

I don't think so? I have been using this pretty successfully against some esp32 firmware images. I appreciate any help or suggestions you may have!

I've been using this for a large reversing project, it does indeed work pretty well :) only blocker to getting this mainlined is then waiting for @emteere to review/merge this

@emteere
Copy link
Contributor

emteere commented Sep 1, 2023

We're working on doing a de-conflict with the orignal PR, some internal further work on the original PR that was almost ready to merge into main, and this PR. My fault for missing this and not communicating what was going on, or maybe your fault for working so fast :-)

If you could hold off doing any changes until then, we'd greatly appreciate it!

There were good things from both forks of the PR, but I think we are almost done. We'd also like to give commit props to both PR submissions which I think we have done.

If all goes well, we'll be pushing it into main in the next week or so. Then you can give it a spin and make any fixes where it doesn't work for you before the next major release.

@emteere emteere added Status: Internal This is being tracked internally by the Ghidra team and removed Status: Triage Information is being gathered labels Sep 1, 2023
@emteere
Copy link
Contributor

emteere commented Sep 1, 2023

Also, if you have a good sample with windowed calling convention that is legal to share, it would help with the final deconflict/review.
Both had an implementation of windowing and I'd like to make sure it is still working well. The sample I have is Call0.

@austinc3030
Copy link
Contributor Author

austinc3030 commented Sep 2, 2023

We're working on doing a de-conflict with the orignal PR, some internal further work on the original PR that was almost ready to merge into main, and this PR. My fault for missing this and not communicating what was going on, or maybe your fault for working so fast :-)

If you could hold off doing any changes until then, we'd greatly appreciate it!

There were good things from both forks of the PR, but I think we are almost done. We'd also like to give commit props to both PR submissions which I think we have done.

If all goes well, we'll be pushing it into main in the next week or so. Then you can give it a spin and make any fixes where it doesn't work for you before the next major release.

Great News!! I will hold off on changes until merged to main. Thanks for the update!

@mumbel
Copy link
Contributor

mumbel commented Sep 16, 2023

@emteere don't know if still relevant, but you'll want an esp32 toolchain to get windowed calls

If you apt-get, it'll probably be esp8266 and non-windowed

https://docs.espressif.com/projects/esp-idf/en/release-v3.0/get-started/linux-setup.html

I made these from an old MIPS build and switched out for xtensa's gcc (has an O3 and O0 in the zip)

XTENSA_PCODETEST.zip

@austinc3030
Copy link
Contributor Author

We're working on doing a de-conflict with the orignal PR, some internal further work on the original PR that was almost ready to merge into main, and this PR. My fault for missing this and not communicating what was going on, or maybe your fault for working so fast :-)

If you could hold off doing any changes until then, we'd greatly appreciate it!

There were good things from both forks of the PR, but I think we are almost done. We'd also like to give commit props to both PR submissions which I think we have done.

If all goes well, we'll be pushing it into main in the next week or so. Then you can give it a spin and make any fixes where it doesn't work for you before the next major release.

Hey @emteere , just curious if there has been any progress on getting this merged and if I should do anything more to this PR such as squashing commits or rebasing on master? Just wanna help out where possible and excited to see this merged!

Thanks!

@ryanmkurtz
Copy link
Collaborator

Progress is still moving in the right direction, despite the slow pace. There is no need to alter your PR...the squashing/rebasing as well as getting the commit authorship correct will be handled on our end. Thank you.

@emteere
Copy link
Contributor

emteere commented Nov 22, 2023

@mumbel btw, thanks for the samples. Helped to work test the windowing.

There is still some work to do on windowing as I think emulation of windowed binaries will be an issue as implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature: Processor/Xtensa Status: Internal This is being tracked internally by the Ghidra team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants