Closed shreyasbharath closed 6 years ago
Hmm, it was developed on Windows. Not sure what the problem is, will take a look at it tomorrow. In the mean time it may be helpful if you can provide the test files that failed.
Regards Peter
On Thu, Apr 19, 2018, 7:36 PM Shreyas Balakrishna notifications@github.com wrote:
Thanks for creating this tool!
I am guessing this tool doesn't support Windows? I get the following output when I run it.
Traceback (most recent call last): File "WCS.py", line 370, in
main() File "WCS.py", line 367, in main print_all_fxns(call_graph) File "WCS.py", line 314, in print_all_fxns tu_width = max(max([len(d['tu']) for d in d_list]), 16)ValueError: max() arg is an empty sequence — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/PeterMcKinnis/WorstCaseStack/issues/3, or mute the thread https://github.com/notifications/unsubscribe-auth/ASlvpN7cWAYOzmigASDW3q6dgK5cyVU2ks5tqR-LgaJpZM4Tcpw- .
Looks like the issue may be caused by one or more translation units that contain zero functions. Can you confirm that this is the case? If so, I will patch the code. In the mean time a work around would be to manually delete the .o, .su, and, *.dfinish file associated with the offending translation units before running the WorstCaseStack script.
Hi, thanks for investigating the issue.
I'll take a look on Monday and get back to you.
It doesn't seem to be the case, I've got a minimal set of .o, .su and .dfinish files and there aren't any translation units with zero functions.
Do you want to patch it anyway and I can try again?
Shreyas
The error is caused by the script finding zero functions to analyze (which
isn't handled elegantly by the script causing the crash). I suspect the
script is not finding all of the relevant input files. Could you verify
that some of the input files end with '*.c.270r.dfinish'. Specifically,
the '270' could be some other number depending on the version of GCC you
are using (you will need to modify line 7 in source code if this is your
problem). Could you also add pprint(tu_list)
to line 348 and make sure
that the result is not empty.
Otherwise, would you be able to provide either of the following:
pprint(call_graph); pprint(tu_list)
. You may manually redact or
obfuscate function or file names if you are concerned about security.Okay so I've had another go at this.
The input files end with .c.310r.dfinish
(GCC v7.2.0), so that was one problem. So I changed rtl_ext
in the script.
I think the script hardcoding read_elf_path = "arm-none-eabi-readelf.exe"
is incorrect, so changed that to readelf.exe
.
Now running into a new problem -
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
Traceback (most recent call last):
File "WCS.py", line 370, in <module>
main()
File "WCS.py", line 351, in main
read_tu(tu, call_graph)
File "WCS.py", line 197, in read_tu
read_obj(tu, call_graph) # This must be first
File "WCS.py", line 53, in read_obj
symbols = read_symbols(tu + obj_ext)
File "WCS.py", line 42, in read_symbols
output = check_output([read_elf_path, "-s", "-W", file]).decode(stdout_encoding)
File "C:\Python36\lib\subprocess.py", line 336, in check_output
**kwargs).stdout
File "C:\Python36\lib\subprocess.py", line 418, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['readelf.exe', '-s', '-W', 'source_api.o']' returned non-zero exit status 1.
Shreyas
Sorry to hear you are having so many troubles.
Your new error is being caused by readelf
not working properly on your
system. My best guess is that this is happening because you have 2
different versions of the gcc compiler suite on your system. You may be
using 'gcc' from one version and 'readelf' from another. Although, it
should only be a problem if the 2 versions have different endianness or bit
width (32 vs 64). 'gcc' and 'readelf' will be in the same directory. Once
you identify the correct 'readelf', use the full path in 'wcs.py'.
Regards Peter
On Thu, Apr 26, 2018 at 12:44 AM, Shreyas Balakrishna < notifications@github.com> wrote:
Okay so I've had another go at this.
The input files end with .c.310r.dfinish (GCC v7.2.0), so that was one problem.
I think the script hardcoding read_elf_path = "arm-none-eabi-readelf.exe" is incorrect, so changed that to readelf.exe.
Now running into a new problem -
readelf: Error: Not an ELF file - it has the wrong magic bytes at the start Traceback (most recent call last): File "WCS.py", line 370, in
main() File "WCS.py", line 351, in main read_tu(tu, call_graph) File "WCS.py", line 197, in read_tu read_obj(tu, call_graph) # This must be first File "WCS.py", line 53, in read_obj symbols = read_symbols(tu + obj_ext) File "WCS.py", line 42, in read_symbols output = check_output([read_elf_path, "-s", "-W", file]).decode(stdout_encoding) File "C:\Python36\lib\subprocess.py", line 336, in check_output **kwargs).stdout File "C:\Python36\lib\subprocess.py", line 418, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['readelf.exe', '-s', '-W', 'source_api.o']' returned non-zero exit status 1. — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PeterMcKinnis/WorstCaseStack/issues/3#issuecomment-384511531, or mute the thread https://github.com/notifications/unsubscribe-auth/ASlvpNJ4DuMV8C418loHh2G9ga6Zrweyks5tsVDDgaJpZM4Tcpw- .
Thanks for creating this tool!
I am guessing this tool doesn't support Windows? I get the following output when I run it.
I ran it like so
python WCS.py
EDIT - I just ran it on Linux and I am getting the same error -
python3 WCS.py