Skip to content

Additional type issues in the presence of dwarf #7963

@waskyo

Description

@waskyo

Version and Platform (required):

  • Binary Ninja Version: 5.3.9085-dev Ultimate (d46c163c)
  • Edition: Ultimate
  • OS: Debian Linux
  • OS Version: unstable
  • CPU Architecture: x86_64 (affected binary is arm32)

Bug Description:

As a follow up to #7943, I am seeing additional type issues. I've uploaded the affected binary to the portal.

  • Serializing type LCL_ParameterChangeHandler generates invalid C, because it's missing enum before LCL_ChangeType. There is an additional function type for which this happens.
  • There are a number of types duplicated (the duplicate gets named _1). One in particular that is causing us trouble is __rlimit_resource_t_1. If we serialize that one alongside __rlimit_resource_t then the compiler complains about redefinition of the enumerators. I noticed that in the exported header, the issue is circumvented by prepending the name of the enum to each of the enum "members":
enum __rlimit_resource : uint32_t {
   __rlimit_resource_RLIMIT_CPU = 0x0, 
...
};

enum __rlimit_resource_t_1 : uint32_t {
  __rlimit_resource_t_1_RLIMIT_CPU = 0x0,
...
};

Ideally the duplicate types wouldn't be there, but if that's unavoidable perhaps the header fix can be applied to when we print individual types through the API?

Steps To Reproduce:
See above

Expected Behavior:
Types generate valid C code like it happens when exporting the header file.

Screenshots/Video Recording:
N/A

Binary:

Portal reference phrase: ocean nova fades progressively

Additional Information:
N/A

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions