Sign in Join

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

Mailing lists / fpc-devel / 2010-12

64bit win dwarf differences between fpc 2.4.2 and trunk

6 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

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

Martin

Vincent did some tests with dwarf on win 64 bit.

with the lates (7.2.5) gdb and trunk results are fine => working.

but with fpc 2.4.2 instead there are strange errors:

Show quoted text 11 lines
84. <info address FPC_BREAK_ERROR> 85. &"info address FPC_BREAK_ERROR\n" 86. ~"Symbol \"FPC_BREAK_ERROR\" is at 0x10000f330 in a file compiled without debugging.\n" 87. ^done 88. (gdb) 89. <-break-insert *4295029552> 90. ^error,msg="Dwarf Error: Cannot find DIE at 0x23c8de referenced from DIE at 0xef [in module C:/Lazarus/bugs/16252/project1.exe]" 91. (gdb)

As you can see the correct address is returned => but attempting to use it to insert a breakpoint (it is the same addr, only decimal) => gets a very strange error.

Exactly the same commands do work, if the exe was compiled with fpc trunk

trunk: http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=19080 2.4.2 http://www.hu.freepascal.org/fpcircbot/cgipastebin?msgid=19079

Martin

Reply by email

Jonas Maebe
to Martin
Martin wrote 5 lines
Vincent did some tests with dwarf on win 64 bit. with the lates (7.2.5) gdb and trunk results are fine => working. but with fpc 2.4.2 instead there are strange errors:

It simply means that there is an error in the DWARF info generated by FPC 2.4.2 that's triggered there.

Jonas

Reply by email

Martin
to Jonas Maebe
Jonas Maebe wrote 8 lines
On 08 Dec 2010, at 21:32, Martin wrote: > Vincent did some tests with dwarf on win 64 bit. > > with the lates (7.2.5) gdb and trunk results are fine => working. > > but with fpc 2.4.2 instead there are strange errors: It simply means that there is an error in the DWARF info generated by FPC 2.4.2 that's triggered there.

Who (if someone) would know more?

e.g
- which revision fixed this?
- does this apply to all and any 64 bit app, or does it depend on the data/structures used by the app (or something else)?

Thanks
Martin

Reply by email

Vincent Snijders
to Martin

2010/12/8 Martin :

Show quoted text 19 lines
On 08/12/2010 21:22, Jonas Maebe wrote: > > On 08 Dec 2010, at 21:32, Martin wrote: > >> Vincent did some tests with dwarf on win 64 bit. >> >> with the lates (7.2.5) gdb and trunk results are fine =>  working. >> >> but with fpc 2.4.2 instead there are strange errors: > > It simply means that there is an error in the DWARF info generated by FPC > 2.4.2 that's triggered there. Who (if someone) would know more? e.g - which revision fixed this? - does this apply to all and any 64 bit app, or does it depend on the data/structures used by the app (or something else)?

Nobody knows?

I did some trial and error by merging some debugging related revsions from http://www.stack.nl/~marcov/fpctomerge.txt
but I failed.
Also I noticed that some revisions are not on that list, for example r14068, probably because it is blocked, but its changes in dbgbase are used in later revisions. So I got stuck.

What would be the best way to proceed to identify the fixes in fpc 2.5.1 for DWARF info to be included in fpc 2.4.3 or a patched fpc 2.4.2?

Vincent

Reply by email

Marco van de Voort
to Vincent Snijders

In our previous episode, Vincent Snijders said:

Also I noticed that some revisions are not on that list, for example r14068, probably because it is blocked, but its changes in dbgbase are used in later revisions. So I got stuck.

I blocked some large revisions (and afaik Jonas has in the past too), because such feature branch merges (that rev is obj-p) will never be merged, and if so, then upset mergetracking is the least of the problems.

What would be the best way to proceed to identify the fixes in fpc 2.5.1 for DWARF info to be included in fpc 2.4.3 or a patched fpc 2.4.2?

Basically reviewing every commit to trunk since fixes_2_4 branching. It should be easy to check against a fixes_2_4 commit log, since that one doesn't contain that many commits to compiler/ (beware of lnfodwarf though).

So

svn log -v on trunk for the range (branchpoint - now), filter for commits to compiler/

same for fixes, but then use this output to select two hands of commits that actually touch compiler/

the difference is the raw list of unmerged changes to the compiler.

(filter makefile fixes and commits to compiler/utils also to avoid garbage)

Reply by email

Vincent Snijders
to Marco van de Voort

2010/12/13 Marco van de Voort :

Show quoted text 20 lines
In our previous episode, Vincent Snijders said: > What would be the best way to proceed to identify the fixes in fpc > 2.5.1 for DWARF info to be included in fpc 2.4.3 or a patched fpc > 2.4.2? Basically reviewing every commit to trunk since fixes_2_4 branching. It should be easy to check against a fixes_2_4 commit log, since that one doesn't contain that many commits to compiler/ (beware of lnfodwarf though). So svn log -v on trunk for the range (branchpoint - now), filter for commits to compiler/ same for fixes, but then use this output to select two hands of commits that actually touch compiler/ the difference is the raw list of unmerged changes to the compiler. (filter makefile fixes and commits to compiler/utils also to avoid garbage)

Thanks.

When I have time, I will try that aproach.

Vincent

Reply by email