Forum > General

questionable function definition display.

(1/3) > >>

440bx:
Hello,

Please refer to the pictures in the attachment. 

The first picture in the attachment shows the little popup window displaying the definition of GetClientRect as taking as parameters a Wnd and a TRECT but that isn't correct.   GetClientRect takes a Wnd and a _pointer_ to a TRECT (which is specified either by "var" or by declaring the parameter as a PRECT instead of a TRECT.)

I am guessing the little popup window is directly or indirectly conrtolled/influenced by Codetools.

The second picture in the attachment shows FpDebug displaying the same incorrect definition for GetClientRect (I'm guessing it is using/reusing information created by Codetools.

Lazarus v3.2, Win 7 64 bit SP1

Useful comments welcome.

Martin_fr:
Actually, FpDebug gets the information from the Dwarf info written by fpc.

Ok, so that is not about "Hwnd" being translated to QWord? (which is done by FPC)


As for "var rect: TRect", fpc (at least current versions) writes into the DWARF info.

- Type "TRect" is a structure. (this is given without pointer, i.e. as a record should be)
- "rect" is of type "TRect"
- The location of the data of "rect" is an expression.
   - Get the frame pointer
   - add a constant (location where in the stackframe the variable is)
   - "deref" (i.e. follow the pointer) in the stack frame.

Data location expressions can be arbitrary complex. Data could even be split across several registers and/or mem-locations. Strings and dyn array have such deref instructions too.

However, there is (in Dwarf) no direct indication if a parameter is declared const/var/...

For real pointers (pointers declared by the user), fpc will include a pointer type, and then make the variable to be that pointer type.

The exact way how such data is encoded has also changed over past versions of FPC. (IIRC)



440bx:

--- Quote from: Martin_fr on April 05, 2024, 12:53:02 pm ---Actually, FpDebug gets the information from the Dwarf info written by fpc.

--- End quote ---
That makes sense.


--- Quote from: Martin_fr on April 05, 2024, 12:53:02 pm ---Ok, so that is not about "Hwnd" being translated to QWord? (which is done by FPC)

--- End quote ---
I figured it shows qword because that's the type behind an hWnd, it would be nice if it showed hWnd.  Is the parameter in dwarf described as qword or hwnd ?  I'm guessing qword and, from what you've stated, FpDebug is relying on how FPC has described it in Dwarf.


--- Quote from: Martin_fr on April 05, 2024, 12:53:02 pm ---However, there is (in Dwarf) no direct indication if a parameter is declared const/var/...

--- End quote ---
I think that's a problem because it causes an incorrect definition to be displayed.


--- Quote from: Martin_fr on April 05, 2024, 12:53:02 pm ---For real pointers (pointers declared by the user), fpc will include a pointer type, and then make the variable to be that pointer type.
--- End quote ---
That's right.  I just tried it and it does it as you described.

refer to the attachment for this next part.  The yellow window shows a bunch of stuff that I suppose is determined by the definition of TRect but, the contents are not really useful (lacks detail) and it makes the window take a fair amount of space.  I'd say the window should just show that a PRECT is a pointer to a TRECT (which is probably obvious but, at least it's only 1 or 2 lines) or show the complete definition of TRECT as well (which will definitely take some space but, could sometimes come in quite handy.)  I think either way is fine except for what it's showing right now (which consumes a fair amount of space yet gives very little useful information.)

ETA:

Removed "codetools" from the thread's title.

Martin_fr:

--- Quote from: 440bx on April 05, 2024, 01:38:32 pm ---
--- Quote from: Martin_fr on April 05, 2024, 12:53:02 pm ---However, there is (in Dwarf) no direct indication if a parameter is declared const/var/...

--- End quote ---
I think that's a problem because it causes an incorrect definition to be displayed.

--- End quote ---
It needs to be addressed in FPC...

Well, FpDebug already has tiny bits of code, that rely on "implementation detail" => e.g., IIRC the difference between "array of char" and "string" is, if fpc wrote a default value or omitted it.... Or something like this. This is something that can break with any new fpc version. But so far, FPC does not encode that difference. (It may be either string<>array or string<>pchar or something of that kind....). It only works for Dwarf 3.

I really don't want to add to much "magic" of that kind. It will end up breaking, and may then not even be fixable....

And yes, it sound like it couldn't break: if there is a deref somewhere then it must have a hidden pointer. => But so does a TObject, which could be encoded that way (currently is not).
And if you have a nested function, the proper way to encode visible locals of the outer function would be using the same deref. (Also currently not done).
So looking for a hidden deref is not a good solution.


--- Quote ---refer to the attachment for this next part.  The yellow window shows a bunch of stuff that I suppose is determined by the definition of TRect but, the contents are not really useful (lacks detail) and it makes the window take a fair amount of space.  I'd say the window should just show that a PRECT is a pointer to a TRECT (which is probably obvious but, at least it's only 1 or 2 lines) or show the complete definition of TRECT as well (which will definitely take some space but, could sometimes come in quite handy.)  I think either way is fine except for what it's showing right now (which consumes a fair amount of space yet gives very little useful information.)

--- End quote ---

Ah, yes that looks like a bug. Displaying types really did not have much attention so far. The function names (and declarations) do exist in the dwarf info.

I don't know if removing the deref of the info is really going to help much. You still get the entire bunch if you hover over TRect instead of PRect. And then there is on deref to omit.

But which ever way that is going to be solved, please report a bug. (Hovering over TRect should include function names and declaration).

About the inclusion of function in any structured typed (record, object, class) => that could be optional. But that is a separate matter.
 

440bx:

--- Quote from: Martin_fr on April 05, 2024, 02:12:23 pm ---It needs to be addressed in FPC...

--- End quote ---
I figured that would be the case.


--- Quote from: Martin_fr on April 05, 2024, 02:12:23 pm ---I really don't want to add to much "magic" of that kind. It will end up breaking, and may then not even be fixable....

--- End quote ---
I fully understand that.  It's a given that sooner or later a lot of that stuff breaks or becomes difficult to keep functional.


--- Quote from: Martin_fr on April 05, 2024, 02:12:23 pm ---Ah, yes that looks like a bug.
<snip>
But which ever way that is going to be solved, please report a bug.

--- End quote ---
Yes, it looked like a bug to me too.  Usually that window shows a lot of useful information and in that particular case, not so much ;)  Reported as bug: 40882

Navigation

[0] Message Index

[#] Next page

Go to full version