Hi to all,

I have a little (I hope useful) propose related to the debug info attached to every compiled file.

I know these info are really useful during the normal debug process and I know also that more beginner programmers do not uses FreePascal because it generates BIG compiled files.

I think the FreePascal debug info contains the full source code of the compiled software, so I suggest to add an option to can add ONLY debug info related to Address -> Unit/Class.Method/Line (without any source code).

So will be possible:

1)...speedup the compiling process (write less bytes on disk and use less RAM to generate compiled file);
2)...the beginner programmers do not stop to uses FreePascal for its BIG compiled files.

What do you think of this my proposal?

Op Sat, 12 Jan 2008, schreef Fabio Dell'Aria:

I think the FreePascal debug info contains the full source code of the compiled software,

Your assumption is incorrect. The debug info contains
* Line info (which source code line belongs to which memory address).
* Type info (information about Pascal data types)
* Variable info (which variable is stored where)

Not possible. Free Pascal's debug information also has to conform to stabs/dwarf specification (the debugger has to understand it), so there is not much freedom to make changes how FPC writes debug information.

Daniel

Could we have debug info as separate file ? If this would be possible I could create release stripped EXE and yet be able to obtain unit/line of exception combining stacktrace numeric output with correct debug info file

Regards
Boguslaw

Bogusław Brandys wrote

Could we have debug info as separate file ? If this would be possible I could create release stripped EXE and yet be able to obtain unit/line of exception combining stacktrace numeric output with correct debug info file

You can already do this: compile a "release executable" with debug info, and then distribute a stripped copy of that executable. The addresses in the stripped executable will match exactly with the addresses in the unstripped one.

Jonas

Hi,

but why isn't simply possible store as Source Code an empty string?

This will be conform to stabs/dwarf specification and in the same time will drastically reduce the final debug info file size.

What do you think of this?

2008/1/12, Jonas Maebe :

Op Sat, 12 Jan 2008, schreef Fabio Dell'Aria:

Hi, but why isn't simply possible store as Source Code an empty string?

Because there is no source code in the exe.

Daniël

On 12 Jan 08, at 17:23, Fabio Dell'Aria wrote:

Hi,

I think that you have not read the previous responses (especially that one from Daniel) properly - there is no source code stored within the debug info.

Tomas

OK, but why do not add the debug info in an external file (conform to stabs/dwarf specification)?

2008/1/12, Tomas Hajny :

Op Sat, 12 Jan 2008, schreef Fabio Dell'Aria:

OK, but why do not add the debug info in an external file (conform to stabs/dwarf specification)?

Because the debugger doesn't support this; the compiler can do it, but, without debugger support it is useless.

Daniël

I think that the real solution for the perceived problem of big executables is having build modes implemented on lazarus:

http://wiki.lazarus.freepascal.org/Conditional_Compiler_Options#Special_build_modes

Why do not simple add an option to avoid the debig info storing for all unit under a specified file path?

Example: LCL or FCL (just setting a file path and the FPC just do not store debug info of all units under this path).

What do you think about this?

2008/1/12, Daniël Mantione :

The FCL in release versions of FPC does not contain any debug info. In general: if you do not want debug info for certain units, do not compile them with debug info.

On most platforms the linker is not inside FPC, so we cannot control in detail which sections from which object files end up in the final executable (so we cannot exclude the debug info of object files stored in particular locations).

Not to mention that spending time on such a feature would be purely wasted time. If people don't use FPC only because using debug info increases the size of their executable: it's their loss, not ours (people who cannot grasp this concept, which is quite common in many tool chains on many different platforms, would probably simply find something else to nitpick about because it is somehow different that what they are used to).

Jonas

Wow! Great!

Could fpc devel team provide application with source code which could translate addresses from bare bone stacktrace generated from stripped executable into full stacktrace with unit/line info using bare bone stacktrace file and executable with debug info included ?

Would be perfect situation to tidy join bare bone stacktrace and debug info to avoid combining stacktrace with incorrect debug executable.Maybe some magic number in stacktrace and debug info ?

Regards
Boguslaw

If someone needs such an application he can create one himself. The existing lineinfo and lnfodwrf units contains already routines to read debuginfo and convert an address to function, source and line information.

Peter

Felipe Monteiro de Carvalho wrote

I think that the real solution for the perceived problem of big executables is having build modes implemented on lazarus:

I agree fully with Felipe. Lazarus needs build modes. Maybe even default it to 'release' build (does Delphi do that) - to shut most of those developers up.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Delphi does that. The downside is that you need multiple copies of the compiled units: a copy with and copy without debug info (as delphi has...)

And obviously, you cannot debug a 'release build', this should be stressed when implementing such a scenario.

Michael.

??
iirc gdb (at least on linux) supports this. This is how I debug gdk libs.

Marc

Can you tell we more about the iirc gdb please?

2008/1/13, Marc Weustink :

OK, but why do not add the debug info in an external file (conform to stabs/dwarf specification)?

I don't understand why debug info should be a big problem. If you don't want it, strip does the job very well. It's just one command away. And you don't need to do it every time you compile your application.

-Bee-

has Bee.ography at:
http://beeography.wordpress.com

Hi,

OK I understand but why do not add a new option to avoid the store of the debug info on the final compiled file (or generated ppu files)?

Currently I must always use "strip" and I cannot use it on "ppu" files?

2008/1/13, Bee :

That option is -Xs. Don't use it in combination with -gl because that adds the debug info again.

Currently I must always use "strip" and I cannot use it on "ppu" files?

Vincent

-Xg will generate a separate .dbg file containing the debuginfo. But the standard debuggers don't support loading the information from this file.

Op zaterdag 12-01-2008 om 20:11 uur [tijdzone +0100], schreef Bogusław Brandys:

Why would we? This is exactly what strip does! It strips out the debug-info to a seperate file. This is wat the -debug package is when you create a .rpm. That -debug package stores the debuginfo. If you install the -debug package, you can use gdb to debug your application. If you don't install it, you can't.

Would be perfect situation to tidy join bare bone stacktrace and debug info to avoid combining stacktrace with incorrect debug executable.Maybe some magic number in stacktrace and debug info ?

Use strip, as the rest of the world does.

Joost.

Op Sun, 13 Jan 2008, schreef Joost van der Sluis:

To be honest, if you would receive a runtime error + stack backtrace output from a user, converting it back to a source line back trace isn't that easy currently. Sure, you can load the debuginfo executable in gdb, then look up the lines one by one, but it would be a time consuming process.

Daniël

Daniel,

This is exactly what I mean.I need to be able to distribute stripped executable and yet be able to convert stacktrace provided by user to the source line info back again. I don't want the user to know where my program failed (unit name and line info).A tool doing this instantly could be appreciated.

Regards
Boguslaw

Fabio Dell'Aria wrote

Can you tell we more about the iirc gdb please?

IIRC -> If I Recall Correctly

This is about plain gdb, since fpide uses gdblib I don't know if it counts foir that too.

Anyway, on my fedora core, I've the option to install a somelib-debuginfo package. This package installs
/usr/lib/debug/usr/lib/libname.so.x.y.z.debug
and
/usr/src/debug/packagename-version/*.c

I didn't read the gdb info again, but from what I recal, gdb automagically searches for any path+lib loaded in /usr/lib/debug if this path+lib.debug exists. If so, it uses that as symbol source. Further, it looks in /usr/src/debug/ for sources.

This is why I wondered about the statement that the debugger doesn't support it.

Marc

Op Sun, 13 Jan 2008, schreef Marc Weustink:

As far as I know this is the full executable as it was before rpmbuild did call strip. It puts the stripped one in the normal rpm and the original one in the debuginfo rpm.

There exists no debugger that can process the .dbg files FPC generates, and gdb cannot read debug info from a file in general. The /usr/lib/debug means gdb simply opens a different executable.

Daniël

I haven't tested this, but from what I read, if strip can preserve the symbols in a separate file then gdb should be able to load them.

http://www.delorie.com/gnu/docs/gdb/gdb_125.html

I am not sure what file format gdb expects for symbols. It may well be, that you can take your original (unstripped) executable for the symbols. Please try it out yourself.

Good luck

Martin

sorry my mailer wrapped that a bit awkward. the important part was:

|symbol-file [ filename ]| Read symbol table information from file filename. |PATH| is searched when necessary. Use the |file| command to get both symbol table and program to run from the same file.

Op zondag 13-01-2008 om 17:48 uur [tijdzone +0100], schreef Daniël Mantione:

No, that won't work. The user has to install the debuginfo, and then run the executable. That's at least how Fedora works and Gnome's bug-buddy.

Joost

Op zondag 13-01-2008 om 19:09 uur [tijdzone +0100], schreef Daniël Mantione:

No, that's not true. It only contains the debug-info. Stripping this from by fpc-x86_64-2.2.0 generated executables doesn't work, btw. I had quite a lot issues with this while packaging fpc and lazarus for Fedora.

Fedora also has a new functionality. It stores an unique ID in the executable and it's corresponding debug-file. So the debugger can check if the files belong to each other. That's not needed if the file is the actual executable.

Joost

When using Lazarus as a frontend for FP you can check the "strip" tag in the project's liker section to create stripped executable (I did not test this myself yet).

-Michael

When using Lazarus you can define auto-stripping in the project options.

-Michael

OK, the build mode could (1) set an environment option that can be checked by $if etc, and (2) switch striping on/off.

As stripping on/off is a simple compiler option in the project setting anyway, build modes don't offer much on the OP's issue.

-Michael

As stripping on/off is a simple compiler option in the project setting anyway, build modes don't offer much on the OP's issue.

The problem is that this works poorly since -Xs is ignored if an user specifies any -g option.

Hi,

I have try to create a .exe with the -Xs option (without any -g options) but the .exe is unusable (the project do not starts also outside the IDE).

2008/1/14, Marco van de Voort :