Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2016-01

Fixing line info units (stabs, dwarf)

7 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Denis Kozlov

Hello,

I want to fix couple of issues with line info units, STABS (lineinfo.pp) and DWARF (lnfodwrf.pp):

1) Back trace is permanently disabled once a module without line info is encountered. This has already been fixed in STABS (r31026, r31025), similar changes can be applied to DWARF.
http://bugs.freepascal.org/view.php?id=13518
http://bugs.freepascal.org/view.php?id=28283

2) When line info data/result are reused, as already implemented in STABS, if an invalid address is supplied then further calls to get line info may result in undefined behavior.
http://bugs.freepascal.org/view.php?id=28288

A possible solution to these problems is to completely disable reuse of line info data/result. This will make line info more stable and resilient, but at a cost of decreased performance due to repeated parsing of same modules. Perhaps stability is more important than speed when debugging.

Otherwise, we can decide not to care about cases when invalid addresses are supplied and continue reusing line info data/result. In this case I will just re-apply fixes from STABS to DWARF.

Any thoughts?

Denis

Reply by email

Michael Van Canneyt
to Denis Kozlov
Denis Kozlov wrote 21 lines
Hello, I want to fix couple of issues with line info units, STABS (lineinfo.pp) and DWARF (lnfodwrf.pp): 1) Back trace is permanently disabled once a module without line info is encountered. This has already been fixed in STABS (r31026, r31025), similar changes can be applied to DWARF. http://bugs.freepascal.org/view.php?id=13518 http://bugs.freepascal.org/view.php?id=28283 2) When line info data/result are reused, as already implemented in STABS, if an invalid address is supplied then further calls to get line info may result in undefined behavior. http://bugs.freepascal.org/view.php?id=28288 A possible solution to these problems is to completely disable reuse of line info data/result. This will make line info more stable and resilient, but at a cost of decreased performance due to repeated parsing of same modules. Perhaps stability is more important than speed when debugging.

Not always: I have web apps where I log a backtrace of errors. So speed is actually important too.

Otherwise, we can decide not to care about cases when invalid addresses are supplied and continue reusing line info data/result. In this case I will just re-apply fixes from STABS to DWARF.

I would go for the latter. Maybe it is possible to make it configurable ?

Michael.

Reply by email

Denis Kozlov
to Denis Kozlov

Patches are ready for both DWARF and STABS.

There is now a global variable "AllowReuseLineInfoData" in each unit. Should it default to TRUE or FALSE?

Description of the variable, as in code comments:
// Allows more efficient operation by reusing previously loaded debug data
// when the target module filename is the same. However, if an invalid
memory
// address is supplied then further calls may result in an undefined
behaviour.
// In summary: enable for speed, disable for resilience.

Denis

Reply by email

Denis Kozlov
to Denis Kozlov

Uploaded updated patch files to mantis.

Also attached here for the reference.

Denis Kozlov wrote 12 lines
On 9 January 2016 at 15:34, Denis Kozlov wrote: > I uploaded patches for line info units: > http://bugs.freepascal.org/view.php?id=28283#c88738 > http://bugs.freepascal.org/view.php?id=28288#c88737 > A little code refactoring problem - "Result" variable is not available in the mode that FPC uses to compile line info units. I will upload updated patches shortly.

Reply by email