The "long" type size seems to be platform dependent, causing hash value
overflow on implementations where "long" is 4 bytes. This addresses the
scenario.
Change-Id: I4e3c0df457e35b139dcc496d832210ba2cb849ba
Relates to https://reviews.llvm.org/D150427,
Each printf call populates buffer with following data
1. Control DWord - contains info regarding stream, format string constness and size of data frame
(see http://gerrit-git.amd.com/c/lightning/ec/device-libs/+/857722 for more info)
2. Hash of the format string (if constant) else the format string itself
3. Printf arguments (each aligned to 8 byte boundary)
Change-Id: I7e320deb343921b4b4cfaf08a2be2883e0bc1f65
This fixes an issue in hostcall when processing printf of a C string.
The calculation to round-up the string size to the next data chunk
didn't include the extra byte for the null terminating character.
Change-Id: I4cf0c250fa4fda253b0db15be461819ffce76d32
The first qword in the printf messages is called the control
qword. If the LSB is set, then the output of the printf is now
redirected to stderr instead of stdout.
Change-Id: I391e04e6e8e0f231fda56f3a6e02703bf50e1924
Vikram
Jeremy Newton
Satyanvesh Dittakavi
agunashe
Siu Chi Chan
Sameer Sahasrabuddhe
Aryan Salmanpour