[fpc-devel] fixing/extending dwarf support // Re: RECENT Commit breaking FpDebug - Dwarf / and not even fully fixing the original issue

[Martin Frb]

On 30/04/2026 22:37, Graeme Geldenhuys via fpc-devel wrote:
> On Thursday, 30 April 2026 18:31:57 BST Martin Frb via fpc-devel wrote:
>> Not exactly what I meant... If you do it this way, then you can only
>> match the entire output against one expectation for it all.
> Maybe not 100% what you described, but it sound like it's very similar in
> concept to my integration tests (not unit tests) I defined for OPDF's cli
> debugger.
>
> https://github.com/graemeg/opdebugger/tree/master/tests/integration
>
> Maybe there is something useful you could reuse.
>
> * Integration tests are trigger by running the 'run_test.sh' script.
> * Each test has *.commands as input and *.expected as what it expects.
> * The test run creates a *.diff file. If that file is not 0 bytes, something
> broke.
>

Yes of sorts.

Only an exact diff is not necessary the best test. We aren't in charge 
of gdb, and if we want to cover a range of versions, then we can't 
always predict the exact formatting. Nor do we need to.

If I want to test a TPoint(10,20) works, then I just need to check that 
it printed x and y with those values (and maybe that its a record not a 
class).
It does not matter if GDB uses round, square or curly brackets. If it 
uses , or semicolon....

With opdf you control all that formatting. You even may want to ensure 
its formatted correct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20260430/f87040c8/attachment.htm>