Hi,

After adding 'tf_dwarf_only_local_labels' to the
flags in i_win.pas (line 105) dwarf2 seems to be working. (Even without -WB00400000).

Cheers,
Willi

Additional remark: The -WB option is still needed, otherwise, e.g., 'disas' is not working correctly in gdb.

Willi

Hi Willi,
I tested and committed this change as rev 16151
in trunk, thanks for this!

What version of the win64 GDB are you using?
I am using a recently generated from GDB cvs HEAD
and I get this:

C:\cygwin\home\pierre\pas\trunk\fpcsrc\compiler>gdb64 ./ppcx64.exe GNU gdb (GDB) 7.2.50.20100928-cvs
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from C:\cygwin\home\pierre\pas\trunk\fpcsrc\compiler/./ppcx64.ex e...done.
(gdb) inf fun err
All functions matching regular expression "err":

File system.pp:
procedure fpc_abstracterrorintern;
(gdb) disas main
Dump of assembler code for function main:
0x0000000100001850 <+0>: push %rbp
0x0000000100001851 <+1>: mov %rsp,%rbp
0x0000000100001854 <+4>: sub $0x40,%rsp
0x0000000100001858 <+8>: callq 0x10000af60 <fpc_initializeunits> 0x000000010000185d <+13>: mov 0x1cd8cc(%rip),%rax # 0x1001cf130 <TC_SYSTEM_EXITPROC>
0x0000000100001864 <+20>: mov %rax,0x23d795(%rip) # 0x10023f000 <U_P$PP_OLDEXIT>

Note that I didn't use the -WB option, so that
the default 0x100000000 is used, but this
doesn't seem to generate disassembly problems.

Thanks again for the 'tf_dwarf_only_local_labels' fix.

Pierre

Pierre Free Pascal wrote

I tested and committed this change as rev 16151 in trunk, thanks for this!

Cool - thanks!

What version of the win64 GDB are you using?

It says 7.2. Probably I should get a newer version. Some output: 0x0000000100001674 <+308>: mov $0x0,%ecx
0x0000000100001679 <+313>: callq 0x10000dcc0
<TYPINFO_finalize_implicit+4294845664>
0x000000010000167e <+318>: callq 0x100009880
<TYPINFO_finalize_implicit+4294828192>
0x0000000100001683 <+323>: mov %rbx,%rcx
0x0000000100001686 <+326>: callq 0x10000dac0
<TYPINFO_finalize_implicit+4294845152>
0x000000010000168b <+331>: callq 0x100009880
<TYPINFO_finalize_implicit+4294828192>
0x0000000100001690 <+336>: mov %rbp,%rcx
0x0000000100001693 <+339>: callq 0x100001710 <PRINT>

Which seems to be totally wrong.

Yes, your output seems to be fine! I'll try upgrading my gdb to a newer version - hope this helps. If this is working, then I think we should switch to DWARF2 on Win64 and close all related bugs in mantis. ;-)

Cheers,
Willi

Willibald Krenn wrote

Yes, your output seems to be fine! I'll try upgrading my gdb to a newer version - hope this helps. If this is working, then I think we should switch to DWARF2 on Win64 and close all related bugs in mantis. ;-)

I upgraded my version of gdb and that fixed the problem. Small disadvantage, though: DWARF debug info disables smart linking :-(.

Anyway, while fpc and gdb are working now, Lazarus fails to pick up the correct address if it is outside of the 32 bit range:

<info address FPC_RAISEEXCEPTION>
&"info address FPC_RAISEEXCEPTION\n"
~"Symbol \"FPC_RAISEEXCEPTION\" is at 0x100008a30 in a file compiled without debugging.\n"
^done
(gdb)
<-break-insert *35376>
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000008a30",at="",times="0",original-location="*35376"} (gdb)

Cheers,
Willi

This seems like a Lazarus specific problem,
the address is certainly cropped to 32-bit somewhere...

I am sorry, but I know almost nothing about
Lazarus source code, so you will need to find someone else to fix this.

An interesting piece of information
would be to know if x86_64-linux is working
without this limitation.

Pierre

14.10.2010 1:52, Willibald Krenn пишет:

Please create a bug report for Lazarus with a test project.

Hello,

I found something I think can be problem with lazarus on win64:

Revision 27315:

Index: trunk/ide/mainbase.pas
===================================================================
--- trunk/ide/mainbase.pas	(revision 27314)
+++ trunk/ide/mainbase.pas	(revision 27315)
@@ -1092,7 +1092,7 @@
        CurMenuItem.Caption :=
SourceEditorManager.SourceEditors[i].PageName;
        CurMenuItem.MenuItem.Checked := SourceEditorManager.ActiveEditor =
SourceEditorManager.SourceEditors[i] ;
        CurMenuItem.OnClick := @mnuWindowSourceItemClick;
-      CurMenuItem.Tag :=
PtrInt(Pointer(SourceEditorManager.SourceEditors[i]));
+      CurMenuItem.Tag :=
Integer(Pointer(SourceEditorManager.SourceEditors[i]));
        inc(ItemCount);
      end;
    end;

If Tag is Integer on 64bit then adding pointers to Tag is a bug. Integer is 32bit in 64bit compiler:

http://wiki.freepascal.org/Integer

Greetings
Andrzej Kilijanski

Dnia 14-10-2010 o 00:26:16 Maxim Ganetsky napisał(a):

And3mD wrote

Hello, I found something I think can be problem with lazarus on win64:

True, using 32-bit wide Tag fields to store pointers is a bad idea on x64. However, the problems with the debugger are more related to the use of StrToIntDef instead of StrToInt64Def... (See attached file.)

Still, even when this is patch applied, debugging with an image base of

32bit is not stable. Whenever I put a breakpoint on a writeln and I

single-step to the next statement, I get a segfault. But this may very well be caused by GDB.

Cheers,
Willi

I added bug report about using Tag as Pointers in IDE

http://bugs.freepascal.org/view.php?id=17642

I know lazarus/fpc sources very poorly, but maybe you can separate some gdb support classes to avoid another SEGFAULTs from IDE on x64.

Greetings

Dnia 15-10-2010 o 21:23:54 Willibald Krenn
napisał(a):

Using tag as a pointer is plain wrong coding, so this change will not make it.

Moreover, streaming it is pure nonsense: There is no guarantee that your pointer will point to the same object, or indeed whether it will exist at all when the program is run.

The IDE code is simply wrong, and should be fixed properly by creating a TMenuItem descendent that contains a reference to the notebook page, and use that class when constructing the menu.

Michael.

I added bug report about using Tag as Pointers in IDE http://bugs.freepascal.org/view.php?id=17642

For some reason (read-only???) I could not add a note there, so I'll present my ideas here:

IMO Tag should become an int64 for all components, to overcome platform and streaming problems. More properties can be introduced, for best compatibility with existing code (Tag64, TagPtr). These properties could be based on the same int64 field, i.e. r/w part of it, and only that field is streamed. And when we just are extending the type, we also could consider to make it big enough to hold a method reference...

DoDi