errors compiling fpdumpdwarf

[440bx]

Hello,

I tried compiling the project "fpdumpdwarf" from the latest Lazarus sourceforge release (v2.2.2) and I'm getting two (2) compile errors about wrong number of parameters passed to a couple of methods.

Attached is a screenshot of the error messages.

What can I do to correct the problems ?


Thank you for your help.

[Martin_fr]

I may have to come back on that one, too late tonight.
It's completely outdated.

You can find how the create call looks in other sources. It will need a memreader and other stuff.

---------------
You can try to build
components\fpdebug\test\dwarfviewer\dwarfviewer

It may need one or 2 lines commented out (or made the missing properties public in the other units / they are likely protected)

All else, when I am more awake.

[Martin_fr]

objdump can also dump some dwarf

[440bx]

Thank you Martin

I normally use objdump for DWARF info but, I was curious about what was available in Lazarus and figured I'd try the test programs that are part of it, among them fpdumpdwarf.

I also had a look at dwarfviewer with mixed results.  Clicking on the "show lines" button usually works fine but, clicking on the button that is above it (I think labeled 'show info" or something like that) causes the program to consume hundreds of megabytes of memory until it causes an exception (apparently due to stack exhaustion.)

Nothing critical though, as you pointed out, objdump dumps DWARF info just about any way a programmer would want to look at it.  That said, it would be nice if, time allowing, those test programs/utilities could be made to work again.  (if I were more adept at OOP, I'd gladly contribute but, I'm more likely to cause more harm than good.)

Again, thank you for the help.

[Martin_fr]

I use Dwarfviewer a lot. I just checked, for the "forms" unit it uses 550 MB.

The problem is that it uses a normal treeview (instead of a VTV). So adding all those items takes time and mem.

It will show you what objdump shows for dwarf info. That is, the dwarfviewer shows all the tags, independent if fpdebug would use them.


I don't know what fpdwarfdump shows.


But both will show a subset of what exists. E.g. Joost added CFI (callstack unwind), and I don't think that fpdwarfdump was updated for that.

On the other hand FpDebug uses some of the linker symbols (e.g. the mangled symbols you may sometimes see in a callstack). Those aren't dwarf. (objdump can show them)

[440bx]

I use Dwarfviewer a lot. I just checked, for the "forms" unit it uses 550 MB.

I'm not having much luck with it.  When I select "forms", after about a minute on my machine, I get an access violation. Also, when I switch back and forth from "dwarfviewer.lpr" to "win32/interfaces.pp" then show lines doesn't work anymore.  It only works the first time either one of them is selected.

But both will show a subset of what exists. E.g. Joost added CFI (callstack unwind), and I don't think that fpdwarfdump was updated for that.

Is the program you're using _not_ the one that is included in the Lazarus v2.2.2 distribution ? (which is the one I'm using)... if that is the case, it would explain why I'm not getting the results you're getting.

I attached 3 screenshots of what I get.  The first one is the program I load into dwarfviewer (I have it load itself.) The second one is the access violation dialog box and, the third one shows the location where it occurred.

One thing, I can use objdump therefore, solving the problem with this program isn't time critical.

Thank you for your help Martin.

[Martin_fr]

Ok, "access violation" may be nothing todo with out of memory....
And well, once crashed, there is no telling what will or wont work.

I use Lazarus 2.3.
But I now tried the 2.2.2, compiled with a 2.2.2 IDE, and the default FPC 322 => all on 64bit Windows.

I didn't get a crash, when looking at win32/interfaces.pp
But that will depend on how exactly you compiled "the exe". That is "the exe" that you load into the dwarfviewer.

Do you still have the exe, that when you try to view causes the crash?
If yes, please send to me in private.

[440bx]

I didn't get a crash, when looking at win32/interfaces.pp

I don't get a crash when looking at "win32/interfaces.pp", I get a crash when looking at "unit1.pas" or "forms.pp" (and possibly others but, those are the two I've used most often to test.)

But that will depend on how exactly you compiled "the exe". That is "the exe" that you load into the dwarfviewer.

I compiled with the "default" configuration and tried that configuration exactly as it was "out of the box" and also changing the debug symbol format from "Dwarf" to "Dwarf with set" and "Dwarf 3 (beta)".  Other than that, no changes whatsoever in the configuration.

Do you still have the exe, that when you try to view causes the crash?
If yes, please send to me in private.

I do but, if I recall correctly, it's about 28MB.  Probably too large to be sent in a message but, if I can put it on Google drive and make it available to you.  Let me know if you want to go that route or some other way that is convenient for you.

Thank you for the help.

[Martin_fr]

OK, well then I get some issue. Haven't waited if it will crash. The counter got stuck (so something wrong) and it was increasing mem usage at a very very slow rate.

However, the Lazarus 2.3 version can read the files (unit1 and forms).
(reading forms takes some time, because adding that much info to a treeview is slow)
After reading them both, mem usage was at 3GB => so a 32bit build wont work....

So whatever causes the issue has been fixed in the main branch.

[440bx]

So whatever causes the issue has been fixed in the main branch.

Good to know.  Thank you.

I'm guessing Lazarus v2.3 is the trunk version and that the "simplest" way to get it would be using FPCUPDELUXE... is this correct ?

[Martin_fr]

So whatever causes the issue has been fixed in the main branch.

Good to know.  Thank you.

I'm guessing Lazarus v2.3 is the trunk version and that the "simplest" way to get it would be using FPCUPDELUXE... is this correct ?

Correct. Though what is the "simplest" way may be subjective. I.e. I have a git clone anyway, and a build from that. So for me, that is simpler.

[440bx]

Correct. Though what is the "simplest" way may be subjective. I.e. I have a git clone anyway, and a build from that. So for me, that is simpler.

Understood   thank you again.

[Martin_fr]

OK, well then I get some issue. Haven't waited if it will crash. The counter got stuck (so something wrong) and it was increasing mem usage at a very very slow rate.

However, the Lazarus 2.3 version can read the files (unit1 and forms).

Found another file, where 2.3 broke. Fixed(mostly), commit pending (not bothered, to interrupt my current other work).

Core issue is that I never implement "address size" in the viewer (fpdebug has it). So it only reads 4 bytes of an address, when there are 8. In rare cases the remainder causes an endless loop.
There still is a tiny chance that this can happen... Work for another day.

[440bx]

Found another file, where 2.3 broke. Fixed(mostly), commit pending (not bothered, to interrupt my current other work).

Core issue is that I never implement "address size" in the viewer (fpdebug has it). So it only reads 4 bytes of an address, when there are 8. In rare cases the remainder causes an endless loop.
There still is a tiny chance that this can happen... Work for another day.

Thank you Martin.  There is no rush, in the meantime whenever I need to look at DWARF info, I'll use objdump.