Sign in Join

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

Mailing lists / fpc-pascal / 2014-03

RTL debuginfo on GDB 7.4+ and OSX Mavericks

6 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

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

Joao Morais

Hello list. I've just upgraded to OSX Mavericks. GDB is no longer installed with xcode5 so I downloaded, compiled and installed GDB 7.6.2 myself. I can debug my own programs, testcases and Lazarus packages if I use Dwarf debuginfo.

However, RTL which I compiled with "-gl" doesn't show filenames, procnames and line numbers anymore in the heaptrc output or stacktraces. If I compile RTL with "-gl -gw", GDB crashes with the following messages. Using FPC_2_6 and Laz_1_2 from yesterday.

While executing the command:
"TGDBMIDebuggerInstruction: "-break-insert +0", "
gdb reported:
"&"linespec.c:2445: internal-error: void decode_line_full(char **, int, struct symtab *, int, struct linespec_result *, const char *, const char *): Assertion `state->canonical_names[i].suffix != NULL' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.""

and

The GDB command:
"-break-insert +0"
did not return any result.
The GDB process is no longer running.

Following [1] I tried to compile GDB 7.3 or below. All of them failed compiling or installing on Mavericks. Is this a known problem? Is there a workaround to see linenumbers and the like on RTL traces on Mavericks?

[1] http://www.sourceware.org/ml/gdb/2012-03/msg00055.html

Thanks!

Joao Morais

Reply by email

Martin Frb
to Joao Morais
Joao Morais wrote 13 lines
However, RTL which I compiled with "-gl" doesn't show filenames, procnames and line numbers anymore in the heaptrc output or stacktraces. If I compile RTL with "-gl -gw", GDB crashes with the following messages. Using FPC_2_6 and Laz_1_2 from yesterday. While executing the command: "TGDBMIDebuggerInstruction: "-break-insert +0", " gdb reported: "&"linespec.c:2445: internal-error: void decode_line_full(char **, int, struct symtab *, int, struct linespec_result *, const char *, const char *): Assertion `state->canonical_names[i].suffix != NULL' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.""

Well that points to a fault in GDB. Additionally there may or may not be an issue with FPC and the line info it wrote.

As for the fault in GDB (crashing, rather than eoither using the line info or reporting an error), I can not predict at which commands it will be triggered.

In Lazarus Options (Tools menu), you can change the "InternalStartBreak" (try Entry or MainAddr). It will lead to an alternative of the "+0" break.

But that does not fix the original issue, and gdb may crash at any other point.

Reply by email

Jonas Maebe
to Joao Morais: Hello list. I've just upgraded to OSX Mavericks. GDB is no longer installed with xcode5…
Joao Morais wrote 8 lines
Hello list. I've just upgraded to OSX Mavericks. GDB is no longer installed with xcode5 so I downloaded, compiled and installed GDB 7.6.2 myself. I can debug my own programs, testcases and Lazarus packages if I use Dwarf debuginfo. However, RTL which I compiled with "-gl" doesn't show filenames, procnames and line numbers anymore in the heaptrc output or stacktraces.

That's because no one has implemented a DWARF lineinfo reader for Mac OS X. There is only one for Stabs. Patches are welcome.

Jonas

Reply by email

Dmitry Boyarintsev
to Jonas Maebe
Jonas Maebe wrote 5 lines
That's because no one has implemented a DWARF lineinfo reader for Mac OS X. There is only one for Stabs. Patches are welcome. Is there DWARF reader for other OS targets?

Is it a matter of parsing the executable (and/or being smartenough to read from an external .dsym file, if available)

thanks,
Dmitry

Reply by email

Jonas Maebe
to Dmitry Boyarintsev
Dmitry Boyarintsev wrote 8 lines
On Wed, Mar 12, 2014 at 8:01 AM, Jonas Maebe < > wrote: That's because no one has implemented a DWARF lineinfo reader for Mac OS X. There is only one for Stabs. Patches are welcome. Is there DWARF reader for other OS targets?

Yes.

Is it a matter of parsing the executable (and/or being smartenough to read from an external .dsym file, if available)

You cannot read it from the executable on Mac OS X, because the DWARF info is left in the object files (to speed up and to reduce memory requirements for linking). So it's either parsing the locations of all object files and then parsing those (if they still exist), or locating and parsing the .dSYM bundle. Only supporting .dSYM bundles would be fine too, as far as I'm concerned.

Jonas

Reply by email

Joao Morais
to Martin Frb: Well that points to a fault in GDB. Additionally there may or may not be an issue with…
Martin Frb wrote 15 lines
On 12/03/2014 11:27, Joao Morais wrote: > If I compile RTL with "-gl -gw", GDB crashes with the following messages: > > While executing the command: > "TGDBMIDebuggerInstruction: "-break-insert +0", " > gdb reported: > "&"linespec.c:2445: internal-error: void decode_line_full(char **, > int, struct symtab *, int, struct linespec_result *, const char *, > const char *): Assertion `state->canonical_names[i].suffix != NULL' > failed.\nA problem internal to GDB has been detected,\nfurther > debugging may prove unreliable."" In Lazarus Options (Tools menu), you can change the "InternalStartBreak" (try Entry or MainAddr) ... that does not fix the original issue, and gdb may crash at any other point.

This trick worked like a charm for the time being. Thank you very much!

Reply by email