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

Jump to bottom

Call-fixup for function gets a data from the code that follows right after a call. #1177

Open
beketata opened this issue Oct 25, 2019 · 18 comments
Open

Call-fixup for function gets a data from the code that follows right after a call. #1177

beketata opened this issue Oct 25, 2019 · 18 comments
Labels
Feature: Analysis Feature: Decompiler

Comments

@beketata
Copy link

My question is regarding to the closed issue #484

I am working on binary file for 8051 CPU compiled by Keil. There is one of library functions ?C?LSTKXDATA which gets dword data from the code follows right after a call.
lab313ru noticed that "They've fixed it in ca44ae9." But in this (latest?) build: ghidra_9.1-BETA_DEV_20190923 it's not fixed.

1

2

As emtreere suggests "One possibilty is to inline the called function, which should cause flow to the correct location." Unfortunately it's also doesn't help due to WARNING: Could not inline here.

The next suggestion from emteere is "The alternative is to create a general call-fixup that is added to the .cspec file to describe the implicit side-effects that happen for the particular call."
Could someone kindly provide me with an example of this call-fixup ? Because the SLEIGH Help do not give a single example and .cspec files in the folder Ghidra\Ghidra\Processors\ do not contains anything similar.
@lab313ru
Copy link
Contributor

Please, provide exact steps you doing to specify the override.

@beketata
Copy link
Author

I have added the new part at the end of "8051.cspec" and changed Casll Fixup for ?C?LSTKXDATA function to Call_2944:

<callfixup name="Call_2944">
  <pcode>
    <body><![CDATA[
      PC = inst_next + 4;
      goto [PC];
    ]]></body>
  </pcode>
</callfixup>

After that decompiled listing looks like:

1

The call of ?C?LSTKXDATA with dword data following by it should decompiled as:

DWORD_EXTMEM_012c = 2;

Unfortunately I could not create the right call-fixup for this kind of issue.

@lab313ru
Copy link
Contributor

Why don't you want to use the Fallthrough override for that?

@beketata
Copy link
Author

Fallthrough helps for assembly listing only, not affecting to the decompiler.

@lab313ru
Copy link
Contributor

It's wrong. It does change the decompiler output too.

@beketata
Copy link
Author

The result after Fallthrough:

2

3

@lab313ru
Copy link
Contributor

Which version are you using?

@beketata
Copy link
Author

I noted this in my question: ghidra_9.1-BETA_DEV_20190923

@lab313ru
Copy link
Contributor

Have you tried to use the master build? I'm completely sure it was fixed in the master code.

Just checked: ca44ae9 was committed after the 9.1 BETA DEV release.

@beketata
Copy link
Author

Thank you for your support.
Could I download builded master code somewhere or should I build it myself?

@lab313ru
Copy link
Contributor

lab313ru commented Oct 28, 2019 •
edited

Never saw any online builds. So, you should build it by yourself.
Because I would not trust somebody's build.

A short build instruction:

  1. (in case of Windows) Download Gradle, add it to PATH
  2. (in case of Linux) install gradle
  3. gradle --init-script gradle/support/fetchDependencies.gradle init
  4. (in case of Windows) Download https://sourceforge.net/projects/winflexbison/ and add the directory to PATH, renaming win-flex, win-bison to flex, bison.
  5. (in case of Linux) install flex and bison
  6. gradle buildGhidra
  7. Wait.

Also, make sure that you're using the JDK 11 in the command line: run java --version.

@lab313ru
Copy link
Contributor

lab313ru commented Oct 28, 2019 •
edited

In case of Windows it also may require to upgrade Visual Studio solution (Ghidra\Features\PDB\src\pdb\pdb.vcxproj) to your VS version. You should also provide a correct VS path here:
GPL\vsconfig.gradle

@beketata
Copy link
Author

Thanks a lot. I am trying to build right now. :-)

@beketata
Copy link
Author

Latest build solves the problem using Fallthrough.
Thank you again!

1

And the next question regarding decompilation of this function ?C?LSTKXDATA, if you allow.
How could I set the function signature for this kind of variable in code? Because the "Storage Location" accepts constant address only.

2

And (xdata dword*)(FUN_CODE_012b + 1) also looks ugly instead of DWORD_EXTMEM_012c.
( xdata dword* is dword*, code dword* is dword* )

@lab313ru
Copy link
Contributor

lab313ru commented Oct 28, 2019 •
edited

As I know: (xdata dword*)(FUN_CODE_012b + 1) is default for the THUMB arm.
I mean, you should call address+1 instead of address. And if your function at FUN_CODE_012b then it looks fine.

@beketata
Copy link
Author

This is binary of 8051 CPU, not ARM.
The meaning of ?C?LSTKXDATA library function is to get dword from code follows right after call and put it to the external memory. So, decompilation of this call in this case should looks like:

DWORD_EXTMEM_012c = 2;

The first argument is a pointer to dword in external memory and the second one is a pointer to dword in code.

@lab313ru
Copy link
Contributor

I don't sure it will decompile the function as you want.

@beketata
Copy link
Author

Not as I want, but as it should be :-)

@gwideman gwideman mentioned this issue Jun 14, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Feature: Analysis Feature: Decompiler
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lab313ru @beketata @ghizard