llnl / llnl/rose

Recovering pre-parsing line numbers of an SgLocatedNode

Open
#275 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
688
Forks
144
PR merge metrics
No merged PRs in 30d

Description

I am using the OFP frontend. Can anyone recommend a means of recovering the pre-parsing line number of an `SgLocatedNode`? I have tried `->get_file_info()->get_line()`, `->get_file_info()->get_raw_line()`, and `->get_file_info()->get_physical_line()`, though each of these gives the line number of the node in the resulting unparsed file which can be dramatically different. I am aware that it is expected behavior to have the unparsed file differ from the original.

What I am trying to accomplish is to automatically map execution counts for lines (from using `gcov` or some such on the original source) to the AST nodes from that line.

A potential workaround is to try running the profiler on a binary compiled using the unparsed files, though this is cumbersome since the unparsed files often do not compile without some manual massaging.

I have also tried adding a line before each line that containing a single comment with the original line number which I then access via `->getAttachedPreprocessingInfo()`, though this admittedly hacky approach also fails since ROSE seems to arbitrarily move some comments around or remove them altogether. I can't help but feel like I'm missing something quite obvious?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the OFP frontend's handling of SgLocatedNode and the get_file_info(), get_line(), get_raw_line(), and get_physical_line() APIs. Review how preprocessing information is attached through getAttachedPreprocessingInfo(), and investigate whether existing source-location data can relate original lines to AST nodes. Done means providing a reliable mapping usable with gcov-style execution counts.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.