|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Fri Mar 20, 2020 6:10 pm Post subject: Cross reference (XRF) file |
|
|
This is a bit long, so bear with me. Bottom line here is a question whether there is an issue with the XRF file that can be fixed/should be fixed, or if this is what you get (which, errors or not, can be very useful).
I was using the XRF file produced by the compiler, and it occurred to be that I could process the file into a different form. Rather than the report which is "Module/Function/Routine uses: xxxxxx" I could gather all the XRF files together and produce a "Where xxxxxx is Used" report/file. I find that more useful if I am making a change at a lower level and need to make sure I haven't forgotten something about the using program
I took one of my larger routines and looked at what the report contained. I noticed certain defining features. So I coded a "scanner" to look for those features. Reviewing the output, I discovered certain features that I had seen/vetted in the original file were not presented the same way in other files. So, I thought I'd ask the question: What should I be seeing?
While the line numbers assigned are some sort of internal number (don't match "actual" numbers), they are not always present. Specifically, the entry for "SUBROUTINE XXXXX" should show a line number where it was used. This is inconsistent.
Similarly, with functions. An interesting side note is that a function declared as EXTERNAL in an include file will show a tilde by the line number, what is sometimes missing is the list of line number where the function is actually used. So, having an INCLUDE that defines a BUNCH of EXTERNAL routines will have a really big list of routines most of which are not referenced in the routine that will only show they were defined, but several of them will also show that they were used (a line number by itself) when they were not.
I have lots of XRF files that have one or all (there are a couple more things) of these discrepancies, and can provide them for review if that would be helpful.
And, I may be the only one trying to use this, particularly in this way. In which case, I can try something else. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Sat Mar 21, 2020 12:49 pm Post subject: |
|
|
Bill, I have used both the /xref and /exp listings for specific purposes in the past, writing filters to process the *.LIS and *.XRF files so generated.
There are more limitations to these listings than those that you have noticed. For instance, it reports a variable CMULT in a module ELEM20NODE as Quote: | DOUBLE PRECISION, {Offset 0 in Common/@@ELEM20NODE!CMULT/} | , DIMENSION(73968) -- there are no common blocks anywhere in any of the source files, so this is probably some form of internal/intermediate representation. Similarly, it reports Quote: | Generating information for SUBROUTINE ELEM20NODE (from module ELEM20NODE) | when there is no such subroutine, and reports PROGRAM TST as SUBROUTINE TST.
If you want more accurate cross-reference and similar listings, you probably have to look elsewhere or roll your own.
As you have guessed, the number of users who still use such listings, and the number of compilers that still generate such listings, are both small and dwindling. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sat Mar 21, 2020 2:18 pm Post subject: |
|
|
Yes, it is (to some) an arcane way to look at your software. But, it works for me.
And, as I age, I find I need a few more tools other than just my memory to remember where each variable is used in COMMON, or where various blocks of code are used and need extra care when updating!
Also, in leaving a trail of breadcrumbs for someone who may follow my passing, I am doing them a favor. Not that this is imminent...... |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sun Mar 22, 2020 11:00 am Post subject: |
|
|
Bill,
Paul is investigating changes to /xref and has provided me with a new option /XREF1 to FTN95 as an initial response to my enquiry.
My enquiry in April 2019 related to:
- errors in the .xrf listing where extra lines were reported, and
- the possibility of having the .xrf file in a .csv format to assist with analysis in Excel.
see http://forums.silverfrost.com/viewtopic.php?t=3974
The new option:
/XREF1 provides a simplified xref file that lists only the routines that are defined in the file together with the routines that each one calls.
This could be used to assist in generating a routine cross reference, which I will try to analyse in a pivot table or similar, else in a Fortran program.
I provide this comment, as if /xref is being revised, perhaps we could provide Paul with a targeted description of what should be in the /xref1 report, how it could be presented and cover what we could then analyse.
I use the term "targeted" as I am not suggesting that this explodes into many different requests that would make it impossible to complete.
My original request was to:
First duplicate a report something like (what I recall as) "/xrefs" in Pr1mos Fortran, which listed only routines or variables that were referenced in the routine. Hence variables in common (or modules) that were not reverenced in the code would not be listed (or have no line numbers)
Next I would like the report to have a structure, which could be read as a .csv file (like /timing) to be analysed (by my program or excel) to produce a cross reference for routines or common/module variables.
Does this align with your post ? |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Sun Mar 22, 2020 1:17 pm Post subject: |
|
|
John, thanks for the additional information, and glad to know I'm not the only one who can use tools like this!
/XREF1 lists all routines, meaning routines I have in an INCLUDE file (to use as callbacks, for example), but don't actually reference in the current program module, are included in that listing. For me, no joy. That said, it is a nice, concise listing, and much easier to scan visually.
I do like your list of desires, though.
Routines actually used would be most helpful to me. The reference to the declaration can be helpful, but would not be required (i.e. where an EXTERNAL type is declared).
Also, like the current listing, the NAME (and kind) of routine is helpful. Currently, SUBROUTINE, INTEGER, CHARACTER, etc. functions are all identified as such. Couple this with the /DUMP list and you could actually reconstruct the arguments list and include that in a cross-reference listing.
CSV format would be fine with me. I would wish to know the contents of the data line to make sure I can use the information.
For example, I can deal with the current XRF file just fine, so long as the line numbering/tagging is consistent (which it is not). Meaning that the definition of the routine being used (if present) is indicated in the listing, and if it is actually used, that this is also indicated in the listing. For me, knowing precisely where it is used, or how many times is irrelevant; it is important that I know which routines/functions are used so I can construct the appropriate where-used list.
I think I've answered your questions, but if not, let me know!
Bill |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Mar 23, 2020 12:35 am Post subject: |
|
|
As a fellow addict, I offer to share with you a small utility that I built by adapting Bill Silvert's old FXREF utility for generating a cross-reference listing for Fortran 77 programs (that old version is still available at http://www.ugu.com/sui/ugu/show?I=software.progutil&F=1111111111&G=Y or from me). For the test program of my previous post http://forums.silverfrost.com/viewtopic.php?t=3868 , which is too long to post but is available for download from Dropbox ( https://www.dropbox.com/s/mr5yyuzihwvwj2n/xlmp11.zip?dl=0 ), my utilty generates the following listing:
Code: | Module refnum_C 3 - 5
call elapse_time(t0) 33
call initpt (n, x, factor) 36
call ssqfcn (m, n, x, fvec) 37
call lmder1 (fcn, m, n, x, fvec, fjac, l 40
call ssqfcn (m, n, x, fvec) 42
call elapse_time (t1) 51
Program main 7 - 65
call ssqfcn (m, n, x, fvec) 80
call ssqjac (m, n, x, fjac, ldfjac) 83
Subroutine fcn 67 - 87
Subroutine ssqjac 89 - 121
Subroutine initpt 123 - 133
Subroutine ssqfcn 135 - 164
call lmder (fcn, m, n, x, fvec, fjac, ld 194
Subroutine lmder1 165 - 200
call fcn (m, n, x, fvec, fjac, ldfjac, i 253
call fcn (m, n, x, fvec, fjac, ldfjac, i 261
call fcn (m, n, x, fvec, fjac, & 266
call qrfac (m, n, fjac, ldfjac, .TRUE., 270
call lmpar (n, fjac, ldfjac, ipvt, diag, 325
call fcn (m, n, wa2, wa4, fjac, ldfjac, 333
call fcn (m, n, x, fvec, & 396
Subroutine lmder 201 - 399
Function dpmpar 400 - 414
call qrsolv (n, r, ldr, ipvt, wa1, qtb, 515
Subroutine lmpar 415 - 545
Subroutine qrfac 546 - 641
Subroutine qrsolv 642 - 733
Function enorm 734 - 787
call system_clock ( clock, rate ) 792
Subroutine elapse_time 789 - 794 |
Please note that the utility is stand-alone, and not tied to the FTN95 compiler in any way.
Last edited by mecej4 on Mon Mar 23, 2020 8:32 am; edited 1 time in total |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Mar 23, 2020 5:57 am Post subject: |
|
|
Awesome, and thanks! I've downloaded it and will take a look.
Bill |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Mar 23, 2020 8:49 am Post subject: |
|
|
Please note that I have not yet made available my utility program for listing subprograms and calls. Since you are interested, I'll collect the pieces and post a zip file in a few hours.
The heart of the utility is a Lex/Flex script, which specifies what patterns the scanner is to search for. Running Flex on the Flex script generates a C program. I have modified the Flex script such that the output C code can be built using Visual C++. I'll provide in the zip file the Flex script, the generated C source files, and a pre-built EXE.
I suggest that you use only the EXE on your Fortran sources, for a while. You can then provide me your feedback on the program's shortcomings, and I can update the program later if feasible. For this limited usage, you will only need the Visual C runtime, which is probably already on your PC, as a prerequisite.
P.S.
Here is the download link for showFsubs:
https://www.dropbox.com/s/shstlv21scjd79g/showFsubs.7z?dl=0
If you modify the Lex script, showFsubs.l, and have GNU Flex and Visual C++, here are the commands to use to recreate the EXE:
Code: | flex -i -t --yylineno showfsubs.l > showfsubs.c
cl /O2 /MD /DYY_NO_UNISTD_H /I. showfsubs.c yywrap.c wingetopt.c
|
|
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Mon Mar 23, 2020 1:34 pm Post subject: |
|
|
Thanks for the offer. I am not in a hurry, so no worries there.
Bill |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Mon Mar 23, 2020 1:50 pm Post subject: |
|
|
It's ready for you to try out. Use the Dropbox link in the post preceding your last one, unzip and run your AV program on the EXE before trying it on a source file. |
|
Back to top |
|
|
wahorger
Joined: 13 Oct 2014 Posts: 1217 Location: Morrison, CO, USA
|
Posted: Tue Mar 24, 2020 3:07 am Post subject: |
|
|
I downloaded the sources, and was pleasantly surprised by the YACC and LEX references in the file. An elegant solution, for sure. I'll give it a workout!
Bill |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|