Chapel: Feature Request: Better output on string representation of First Class Functions

[krishnadey30]

Currently string representation of a FCF return something like this.

proc justCheck(i: int) {
  writeln(i);
}
writeln(justCheck:string);

Output

{}

One of the suggested output by @LouisJenkinsCS:
Name and virtual Address

justCheck(i : int) @ 0xBADADD

[krishnadey30]

One of the way suggested by @bradcray is this.

The way a class author can change the default way an object is printed is by defining a writeThis() method on it. So to change how FCFs are printed out, inserting code to have the compiler create something like:

proc ct.writeThis(out) {
  out.writeln(fcf_name);
}

should do the trick.

[bradcray]

@LouisJenkinsCS's suggestion to print out the virtual address I think only makes sense for --developer (or --power-user) mode as a typical user wouldn't have anything much they could do with it. It also raises a question about what to print out on a multi-locale run since each locale could have different address scrambling for security measures. Would you just print out the current locale's address? All of them? And is the address being printed out that of the function itself or of the class wrapping the function?

[LouisJenkinsCS]

If Address Space Layout Randomization is used, then either... A) Print out the PIC offset from the base of the text segment, or preferably B) The address of the function on the locale calling said function.

Edit: If it is a first-class function, I still want the address of the function (I.E to this method). Since the class is compiler generated, it wouldn't be of interest to me since I couldn't even represent said class in Chapel.

[lydia-duncan]

I'm not sure I understand what would be done with the address even in developer mode, can you explain how you would use it in Chapel code?

[LouisJenkinsCS]

For debugging.

[bradcray]

For debugging.

I worry like we're going down a rathole given that we don't even have a basic printing function yet (not that that should be too hard to add...), but... What makes FCF's more in need of printing address information than, say, variables? Should we expect people needing the address to just use the debugger to get this address information as they would for other types? (I'm asking in part from a perspective of the K.I.S.S. principle and in part because I don't think that information would be simple to add to a writeThis() routine...).

Keep in mind that FCFs in Chapel (at least today) are not C-like function pointers, so it's not as though the value of a FCF variable is that address...

[LouisJenkinsCS]

Because as you stated before, FCFs are implemented as classes. I'd want the address to be the actual address of the method/ function being invoked. I am assuming that a naive approach to printing a FCF will result in getting a pointer to a class on the heap, but I would want the address of something in the code segment.

Question, which is related but slightly off topic: how do I set a breakpoint inside of a FCF if the class name and likely method is compiler generated and I have no way to get the actual address of the code being executed?

[bradcray]

I believe you're correct that there's no dependable way for the programmer to reason about the name of the compiler-generated method that implements the FCF. It's implemented as the class's this() method, so will have the base name this_chpl, but then if you had 10 FCF's (or other classes implementing this methods, the compiler would do further munging to the name to make sure it was unique in the generated C code.

It seems to me that you might want to make a feature request asking that FCF variables support a power user method pointerTo() (or c_pointerTo()?) that would give you the address of this method (and/or the address of the function it's going to call, which may be more useful / intuitive?). Such a method strikes me as being more useful, precise, and orthogonal than having writeThis() print out the address to the console.

[LouisJenkinsCS]

Alright, I'll do that. I was just suggesting that it print out the virtual address since it hits two birds with one stone, but I'll ask for a way to query this kind of functionality.

[bradcray]

I think it will require two stones to hit those two birds.

For those following this, Louis has opened #13230.

[bradcray]

PR #13232 makes a start at this. I may not have time to wrap it up before traveling if someone else wants to run with it after I leave.

[LouisJenkinsCS]

Is PR #13232 only printing out an empty parameter list? Can it not print out the fn.argTypes : string as well? (I.E print fn.name + fn.argTypes : string)

[bradcray]

Can it not print out...

Not without additional work.

[ben-albrecht]

13232 is a step in the right direction. Thanks @bradcray!

I hope that future work can expose additional information such as arguments, where clauses, and address. However, it's not clear to me if these should be part of the writeThis output or something separate, e.g. a fcf.arguments field.

In any case, I think #13232 should close this issue, and these additional requests should be filed separately as general FCF improvements.