PeterMcKinnis / WorstCaseStack

This program is used to do static stack analysis on C source code to determine the worst case stack usage for each function
BSD 3-Clause "New" or "Revised" License
87 stars 28 forks source link

Does this work on Windows? #3

Closed shreyasbharath closed 6 years ago

shreyasbharath commented 6 years ago

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

Traceback (most recent call last):
  File "WCS.py", line 370, in <module>
    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

EDIT - I just ran it on Linux and I am getting the same error -

python3 WCS.py

Traceback (most recent call last):
  File "WCS.py", line 370, in <module>
    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
PeterMcKinnis commented 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- .

PeterMcKinnis commented 6 years ago

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.

shreyasbharath commented 6 years ago

Hi, thanks for investigating the issue.

I'll take a look on Monday and get back to you.

shreyasbharath commented 6 years ago

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?

PeterMcKinnis commented 6 years ago

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:

  1. The code (or some subset of the code) that reproduces the problem.
  2. The output of the code when line 367 is replaced with pprint(call_graph); pprint(tu_list). You may manually redact or obfuscate function or file names if you are concerned about security.
shreyasbharath commented 6 years ago

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.
PeterMcKinnis commented 6 years ago

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- .