You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When parsing header files, the parser ignores #error when it should not. When it correctly does fail due to an #error it fails to identify the cause of the problem.
To Reproduce
There are four very simple header files in the attached tar file. To reproduce, simply process the header files using two different orders: bbb.h aaa.h ccc.h and bbb.h aaa.h ccc-fixed.h. You can use the Ghidra UI, or you can achieve the same results using CParserUtils.parseHeaderFiles
Expected Behavior
Ghidra improperly reports success when the parse order is bbb.h aaa.h ccc.h although it does have a message with a useful warning (but it should have failed). Alternatively, Ghidra properly reports failure if the parse order is bbb.h aaa.h ccc-fixed.h but then it provides meaningless information about the actual error.
The only difference between ccc.h and ccc-fixed.h is the inclusion of a typedef before the #error Why should this affect the success or failure of parsing? The files were designed such that the only valid parse order is aaa.h bbb.h ccc.h
There are two phases to the parsing just as in normal header parsing.
The first phase is the Pre-processor that handles macro expansion. That would catch the error and fail.
The second phase the CParser will parse the output of the pre-processor.
My suspicion is that in both cases the second phase parse is getting to run when the first phase encountered an error.
In the first case the output has stopped at the error, but is still parseable C, so the CParser can parse it. The error isn't stopping the second phase.
In the second case where it fails and provides an error, it has allowed the second phase to occur but the output fed to the second phase is only pre-processor parsed up to the error, and thus the CParser also fails with a parse error. The CParser shouldn't get kicked off if the PreProcessor fails.
It might have been as designed originally to allow processing so one could extract as much type information as possible. This probably isn't the best behavior, or at least should be an option to push through any error conditions that is off by default. I've seen some #error conditions that can be ignored in special cases, I think when parsing AVR8 header files, but this probably isn't the norm.
Describe the bug
When parsing header files, the parser ignores
#error
when it should not. When it correctly does fail due to an#error
it fails to identify the cause of the problem.To Reproduce
There are four very simple header files in the attached tar file. To reproduce, simply process the header files using two different orders:
bbb.h aaa.h ccc.h
andbbb.h aaa.h ccc-fixed.h
. You can use the Ghidra UI, or you can achieve the same results using CParserUtils.parseHeaderFilesExpected Behavior
Ghidra improperly reports success when the parse order is
bbb.h aaa.h ccc.h
although it does have a message with a useful warning (but it should have failed). Alternatively, Ghidra properly reports failure if the parse order isbbb.h aaa.h ccc-fixed.h
but then it provides meaningless information about the actual error.The only difference between
ccc.h
andccc-fixed.h
is the inclusion of a typedef before the#error
Why should this affect the success or failure of parsing? The files were designed such that the only valid parse order isaaa.h bbb.h ccc.h
Screenshots
Attachments
ghidrabug.tar.gz
a gzipped tar file containing four files
Environment
Ghidra version 11.2 using headless analyzer and a custom script,
Ghidra version 11.03 using UI
The text was updated successfully, but these errors were encountered: