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

Fileinfo specification #6

Open
3 tasks done
dalance opened this issue Nov 30, 2020 · 2 comments
Open
3 tasks done

Fileinfo specification #6

dalance opened this issue Nov 30, 2020 · 2 comments

Comments

@dalance
Copy link

dalance commented Nov 30, 2020

Checklist

  • Did you write out a description of the feature you want to see?
  • Did you look around for any related features?
  • Did you specify relevant external information?

Feature Description

In spec.pdf, fileinfo is defined as info = @[string], but the format of string is not defined.
I think this missing will cause compatibility issues with other front-ends except Chisel in future.
Additionally, the current string format of Chisel lacks absolute file path.
This means back-ends of FIRRTL can't find the original source codes.

So I think the specification of fileinfo should be defined like below:

info = @[ [[absolute_file_path]] [[line]]:[[row]] ]
absolute_file_path = string
line = int
row = int

This specification is an idea, and I think it can be improved.
For example, file path encoded as URI. It is described at chipsalliance/firrtl#1695 (comment).

The debug information of LLVM-IR may be helpful.

Type of Feature

  • documentation

Related Features

#8

External Information

https://llvm.org/docs/SourceLevelDebugging.html#c-c-front-end-specific-debug-information

@ekiwi
Copy link
Contributor

ekiwi commented Dec 2, 2020

Currently the format is mostly aimed at direct human consumption.

Imho if we want to include the full path info, we cannot just include it at the end of every line, as that would more than double
the size of firrtl files. Instead we would probably want to have a global lookup table similar to LLVM. This will not be an obstacle to tools and might even reduce the size of the firrtl file (since every file name would only have to be written out exactly once). However, it will make it much harder for humans to benefit from the information, since they will need to resolve the indirection manually.

@chick
Copy link
Contributor

chick commented Dec 3, 2020

Rendering the putative machine friendly source information would be a good addition to the IntelliJ firrtl plugin

@seldridge seldridge transferred this issue from chipsalliance/firrtl Mar 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants