Hello, FPC developers' list

We have a trouble in lazarus. We need to open units and include files wich gdb returns to us. The problem is that gdb repors them without full path.
At moment if we get some file we expand it path using known project and packages paths (lcl is a package too).

But in case of .inc files we have a problem that name is not unique (this can be also true for units but happens less frequent). For example lists.inc is placed in
C:\programming\fpc\packages\gnome1\src\zvt\lists.inc and C:\programming\fpc\rtl\objpas\classes\lists.inc here.

Thus we need to parse that lists.inc files and compare it with method/function/procedure from the stack.

For example:
TLIST__DELETE lists.inc 123
We can finds two lists.inc (one in the packages\gnome and second in the rtl\objpas\classes). Then we need to parse them and look for TList.Delete.

This all (searching and parsing) is not simple and requires much time.

What solution fpc team can suggest? How this solved by mseide developers?

Best regards,
Paul Ishenin.

Paul Ishenin wrote

We have a trouble in lazarus. We need to open units and include files wich gdb returns to us. The problem is that gdb repors them without full path.

It's because there is no path information in the debug information.

What solution fpc team can suggest?

Use DWARF :)

I don't know where the decision comes from to not include any path information in the stabs debug information that FPC generates (gcc does include it by default). It is possible to specify a full path for each file in stabs. That path would obviously be invalid if you copy the program to another machine though (or if you access it from another machine over a network share). Maybe you cannot tell gdb to search elsewhere for the source if you include a full path? A command line option could be added to make FPC store full paths in the stabs debug info though. Feel free to file a feature request

In case of DWARF, the path is split in two parts: a base directory, and then paths to files relative to this base directory. That makes it easier to specify full paths and still be portable to other file system layouts, I guess (although I don't know how gdb handles this either).

Jonas

Zitat von Jonas Maebe :

True, but a /bla/bla/rtl/objpas/classes/lists.inc is much better than a lists.inc.

Maybe you cannot tell gdb to search elsewhere for the source if you include a full path? A command line option could be added to make FPC store full paths in the stabs debug info though. Feel free to file a feature request

Thanks for the advice.
Paul, will you do that?

Mattias

In our previous episode, Jonas Maebe said:

Hmm. But both C and FPC allow to specify multiple source/include paths, and binaries can be crafted from objects from different runs.

The only way I can see this working is to use absolute paths and let the linker normalize this to the longest common directory or so?

The base path is set/stored per compilation unit.

Jonas

Feel free to file a feature request

what about patch? :) what units should be studied to make such patch?

Thanks,
Dmitry

P.S. AFAIK, Marc told me, that FPC does not generate DWARF line info for yet, so it's not possible to use DWARF to find files or anything else... I don't remember exact, so i can be wrong here.

dmitry boyarintsev wrote

> Feel free to file a feature request what about patch? :) what units should be studied to make such patch?

compiler/dbgstabs.pas

P.S. AFAIK, Marc told me, that FPC does not generate DWARF line info for yet, so it's not possible to use DWARF to find files or anything else...

That's incorrect.

Jonas

Mattias Gärtner wrote

Thanks for the advice. Paul, will you do that?

I've done: http://bugs.freepascal.org/view.php?id=13248

I have no idea whether more info must be placed there? The only thing is that we need to have this problem solved before lazarus 1.0 release or we need to invent some tricky path resolver inside lazarus itself.

Best regards,
Paul Ishenin.

Indeed, iirc its one of the first things I added to fpc (and broke).

Marc

Paul Ishenin wrote

How this solved by mseide developers?

MSEgui uses includefiles for headers in platform specific units (msesysintf.pas, mseguiintf.pas) only, so there are not many include files in the MSEgui framework and the names are unique.
In order to search files which are reported by gdb MSEide uses the absolute path if available. If not found it searches relative to the make directory ('Project'-'Options'-'Make'-'Make Directory'). If not found it scans the listed directories in 'Project'-'Options'-'Debugger'-'Source directories' where ? and * wildcards can be used.

Martin

And how does MSEGui find lists.inc?
For example on indexoutofbounds exception?

Mattias

http://www.msegui.homepage.bluewin.ch/pics/exception.png http://www.msegui.homepage.bluewin.ch/pics/debugoptions.png

The links show a typical situation, lists.inc is found by ${fpcdir}rtl/objpas/classes/
MSEide does probably the same as Lazarus to find gdb reported files.

Martin

Thanks to Jonas. We don't need to write so big debug paths anymore. He successfully fixed an issue with path in the stabs in r12812.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

Thanks to Jonas. We don't need to write so big debug paths anymore. He successfully fixed an issue with path in the stabs in r12812.

Jonas, can you look futher. I pasted one example here (executed -file-list-exec-source-files)
http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=8928 It shows that some include files still does not have full paths while some have. As result executing of "-symbol-list-lines
C:\programming\lazarus\lcl\include\messagedialogs.inc" fails but "-symbol-list-lines messagedialogs.inc" works. But for files with fullname it works ok (for example for
C:/programming/fpc/rtl/win/winres.inc).

Best regards,
Paul Ishenin.

In trunk/r12933 you can now force the compiler to always store absolute path for include files using -gostabsabsincludes. See the svn comment for why it's not the default (gcc also never does this, you can't even force it to do that). There is no way to specify a separate base directory for an include file in stabs, as opposed to for the main source file.

The reason that gdb previously already found an absolute path for some include files, was probably that they were located in the same directory as the main unit file.

Jonas

Sorry, for me it is somehow strange that this works different:

{file="C:/programming/fpc/rtl/i386/i386.inc",fullname="C:/programming/fpc/rtl/i386/i386.inc"} and
{file="./include/messagedialogs.inc"}

main unit file is located in
C:/programming/mytest/0.9.27/SafeCall/project1.lpr

Best regards,
Paul Ishenin.

Did you recompile everything with -gostabsabsincludes? And did it change anything at all?

Jonas

No, I had not. I'm asking about default fpc behavior. I just found it strange that 2 files are handled different while both have .inc extension.

Best regards,
Paul Ishenin.

They are not necessarily handled differently. When gdb finds an include file specified in the debug information, then it will always display the full path in the output above. If it doesn't find it (for whatever reason), it will display what's stored in the debug information (which can be a relative path).

Jonas