Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write seperate pass for function dot file generation. Don't overwrite dot files. #87

Open
zjuchenyuan opened this issue Feb 24, 2021 · 5 comments
Labels

Comments

@zjuchenyuan
Copy link

Different binaries may have the functions with same name, the most common one is the main function.

When generating dot files, only function name is kept in naming the dot file for this function. Therefore, for preprocessing building process, only the last compiled binary's main function's dot file will be retained.

For example, following the instruction from README, to build xmllint, you give make all, and I get this cfg.main.dot:

digraph "CFG for 'main' function" {
        label="CFG for 'main' function";

        Node0x38c0b10 [shape=record,label="{gjobread.c:288:}"];
        Node0x38c0b10 -> Node0x39ce120;
        Node0x39ce120 [shape=record,label="{gjobread.c:296:}"];
        Node0x39ce120 -> Node0x39ce400;
        Node0x39ce120 -> Node0x39ce020;
        Node0x39ce400 [shape=record,label="{gjobread.c:297:}"];
        Node0x39ce400 -> Node0x39cd710;
        Node0x39ce400 -> Node0x39cd7b0;
        Node0x39cd710 [shape=record,label="{gjobread.c:299:}"];
        Node0x39cd710 -> Node0x39cd760;
        Node0x39cd7b0 [shape=record,label="{gjobread.c:301:}"];
        Node0x39cd7b0 -> Node0x39cd760;
        Node0x39cd760 [shape=record,label="{gjobread.c:303:}"];
        Node0x39cd760 -> Node0x39ce370;
        Node0x39ce370 [shape=record,label="{gjobread.c:296:}"];
        Node0x39ce370 -> Node0x39ce120;
        Node0x39ce020 [shape=record,label="{gjobread.c:306:}"];
}

Since example/gjobread is the last built binary, its main function dot is kept, not the target binary xmllint.

I think this is a problem leading to wrong CFG distance analaysis, and I suggest:

  • use make xmllint to avoid building other binaries
  • change the generated dot file names (maybe keeping same name files with .1 .2?)
@mboehme
Copy link
Collaborator

mboehme commented Feb 24, 2021

Thanks ChenYuan! I'll add make xmlint to our Readme.md.

In the longer run, we need to update our scripts so we don't override dot-files.

mboehme added a commit that referenced this issue Feb 24, 2021
Quick fix for #87
@mboehme
Copy link
Collaborator

mboehme commented Feb 25, 2021

Just reopening, so we don't loose track.

@mboehme mboehme reopened this Feb 25, 2021
@zjuchenyuan
Copy link
Author

Do not override dot files is easier said than done. When compiling a single compile unit, I think the compiler do not know which binary this unit will be built into. So, the compiler cannot just name the dot file as format cfg.<binary>_<function name>.dot

Even if we keep same named files using like .1, .2, which file should distance calculation use?

I think the easist way to solve this issue is to require user to just compile target binary, like make xmllint, just add the target binary as a make argument should be enough.

@mboehme mboehme mentioned this issue Mar 8, 2021
8 tasks
@Liblor
Copy link

Liblor commented Mar 18, 2021

One way to address this, is to extract the function dot file generation part of the pass into a separate pass. Then one could use opt with this new pass to create the dot files in the genDistance.sh/gen_distance_fast.py, the files could then be put into a dedicated subfolder.

Something like

opt -gen-func-dot -name xmllint xmllint.0.0.preopt.bc

@mboehme
Copy link
Collaborator

mboehme commented Mar 19, 2021

@Liblor, this is a great suggestion!

@zjuchenyuan You are welcome to submit a pull request if this works for you.

@mboehme mboehme changed the title Wrong dot files being analayzed Write seperate pass for function dot file generation. Don't overwrite dot files. Jul 23, 2021
@mboehme mboehme added the bug label Jul 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants