[fpc-devel] Are debug info in PPU already encoded stabs/dwarf?

Well what happens when: - you compile a package with stabs - your program with dwarf Or vice/versa. What will be in the final exe? Is the debug info in the ppu already format specific, or generic. Will the stabs end up together with the dwarf? Martin

Re: [fpc-devel] issue examining pointer/array/record elements with GDB

On 08/09/2011 17:03, Seth Grover wrote: If I compile this program with FPC 2.4.4 with debugging (-g), line numbers in backtraces (-gl), and dwarf debug information (-gw), then fire up GDB (I'm in Linux, by the way), put a breakpoint at the writeln, then run, observe what happens: (gdb) print MYR

[fpc-devel] the new resourcestring in const translation

fpc recently added the ability to translate const Foo: String = resourcestring; if resourcestring changes so does Foo Any way to work around this? because in C:\lazarus_latest\components\synedit\syneditstrconst.pp there are a lot of strings initialized that way with the intend of the old be

[fpc-devel] wrong line for deprecated

Just noticed the following program Project1; var a: integer deprecated; begin if 1 = a then writeln; end. project1.lpr(5,3) Warning: Symbol "a" is deprecated Which points to the "then" on the line after "a" is used. (even if the lines a joined, it always points to the next token) If a is

[fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)

h gdb isn't necessarily able to call them). So my question here is, if it is (for each or any of the debug types) possible to encode them into the class declaration,even if none functional? so ptype TFoo would return them in the list of fields and proc

Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)

ide info about properties; but leave the actual name mapped to the field (were appropriate) so the expression evaluation would still work Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] bounty: FPC based debugger

On 12/09/2011 08:47, Torsten Bonde Christiansen wrote: I really miss the easy use of the Delphi debugger from D7. Especially the live inspection of object during single step of the code. In that case you (all involved) better specify the required features. The debugger itself (in my understand

Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)

On 12/09/2011 10:55, Hans-Peter Diettrich wrote: Martin schrieb: More than that, Lazarus is not the only way to use the info, people use other IDEs or gdb directly => all that needs to be considered. You can't have one tool for everybody and everything. A debugger can not (and

Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)

On 12/09/2011 11:06, Hans-Peter Diettrich wrote: IMO debugging support was one of the reasons, why Kylix was based on Wine, and the cross-platform versions of Delphi use remote debugging only. For that implementation a tiny (remote) debugger interface is sufficient, and the IDE can implement

Re: [fpc-devel] bounty: FPC based debugger

On 12/09/2011 11:10, Graeme Geldenhuys wrote: Here is what I would consider a "debugger": - command line interface at least - watches since lazarus displays watches, using gdb, maybe this should be more specific? - Yes, certain expressions are not supported, or not well supported. -- stri

Re: [fpc-devel] bounty: FPC based debugger

On 12/09/2011 11:51, Martin Schreiber wrote: The big issue, is that gdb often scopes them wrong, and you loose the watch point before you it triggers MSEide has popup menu functions 'Address Watchpoint 8', 'Address Watchpoint 16', 'Address Watchpoint 32' and &#

Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

Anyone care to comment on those ideas? Are they worth to be made a feature request? And if so, which of the proposed ideas should be made into a feature request? On 11/09/2011 23:15, Martin wrote: Like it was done for properties that directly map to a field. The now are somehow encoded, so

Re: [fpc-devel] bounty: FPC based debugger

On 12/09/2011 13:07, Graeme Geldenhuys wrote: On 12/09/2011 13:49, Martin Schreiber wrote: True. And because we know what it means to develop something new from scratch and because I know that I don't want to invest several years into development of a FPC debugger and because we know that

Re: [fpc-devel] bounty: FPC based debugger

On 12/09/2011 13:11, Jonas Maebe wrote: On 12 Sep 2011, at 12:23, Martin wrote: The big issue, is that gdb often scopes them wrong, and you loose the watch point before you it triggers If you use an expression in a watch point, gdb will reevaluate that expression if a value used in the

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

On 12/09/2011 18:32, Jonas Maebe wrote: On 12 Sep 2011, at 14:07, Martin wrote: Anyone care to comment on those ideas? Are they worth to be made a feature request? And if so, which of the proposed ideas should be made into a feature request? I really don't like hacks like that. They

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

On 12/09/2011 19:08, Martin wrote: On 12/09/2011 18:32, Jonas Maebe wrote: On 12 Sep 2011, at 14:07, Martin wrote: Anyone care to comment on those ideas? Are they worth to be made a feature request? And if so, which of the proposed ideas should be made into a feature request? I really don&#

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

On 12/09/2011 19:14, Martin wrote: On 12/09/2011 19:08, Martin wrote: On 12/09/2011 18:32, Jonas Maebe wrote: While not a complete solution either, couldn't you use the information from the Lazarus codetools to figure out which properties exist? If that's currently not possible b

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

On 12/09/2011 19:31, Jonas Maebe wrote: On 12 Sep 2011, at 20:20, Martin wrote: Could not properties mapping to a function be implemented the same way => normal functions are already listed in "ptype" so public property Counter: Integer read GetCounter could appear th

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

On 12/09/2011 20:46, Joost van der Sluis wrote: On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote: On 12 Sep 2011, at 20:20, Martin wrote: Could not properties mapping to a function be implemented the same way => normal functions are already listed in "ptype" so publ

debug hints in lazarus [Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]

cced to lazarus list. please switch list. On 12/09/2011 21:28, Hans-Peter Diettrich wrote: Martin schrieb: Mind, I do NOT want to play down say that the lack of property support. I didn't notice until now that my problems may be related to properties. AFAIR I also couldn't insp

lazarus debug with gdb [Re: [fpc-devel] bounty: FPC based debugger]

cced lazarus On 12/09/2011 22:51, Hans-Peter Diettrich wrote: Paul Ishenin schrieb: 12.09.2011 19:00, Martin Schreiber wrote: True. And maintaining all platforms is a fulltime job too. And a FPC only debugger can not debug linked c libraries which we can do currently with gdb. And think of

Re: [fpc-devel] bounty: FPC based debugger

On 12/09/2011 22:16, Hans-Peter Diettrich wrote: Another wish: separation of debug info and debug code. Currently I can't step into packages or FCL/RTL, without compiling these first for debugging. But doing so puts in all the debug code (output...), residing in the units. What I want is a de

Re: lazarus debug with gdb [Re: [fpc-devel] bounty: FPC based debugger]

On 12/09/2011 23:18, Martin wrote: However, I still recommend trunk => a lot of fixes have been applied. And if you are on windows, I recommend gdb 7.3 32bit: http://svn.freepascal.org/svn/lazarus/binaries/i386-win32/gdb/bin libraries go into the same folder as gdb. 64 bit => n

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

On 13/09/2011 10:31, Flávio Etrusco wrote: GDB supposedly has support for reverse execution/walking back; I don't even know whether it really works for C, not to mention FPC calling conventions, but if it does it would be a killer ;-) afaik, requires hardware support. most intel cpu don't ___

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

On 13/09/2011 12:11, Jonas Maebe wrote: afaik, requires hardware support. Support has to be implemented in GDB for each architecture before it will work (currently it's implemented for x86 and ARM, afaik), but it does not rely on special hardware support. http://www.gnu.org/s/gdb/news/re

the feature request, that started the discussion [Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)

alue of this attribute is a reference to the sibling entry of the entry to which the attribute is attached On 12/09/2011 21:13, Martin wrote: On 12/09/2011 20:46, Joost van der Sluis wrote: On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote: On 12 Sep 2011, at 20:20, Martin wrote: Could n

Re: [fpc-devel] Unicode support (yet again)

On 15/09/2011 10:38, Michael Schnell wrote: On 09/15/2011 11:06 AM, Graeme Geldenhuys wrote: and to show you AGAIN how flawed your "direct index access to a character" example is. It's not "my" intend to use it. I'll never use it as I do know that it is bound to create problems. But it is what

[fpc-devel] 0020225: issue examining pointer/array/record elements with GDB

http://bugs.freepascal.org/view.php?id=20225 I did run a test on w32 vista with gdb 6.7.5 / 7.0 / 7.2.1 / 7.3.1 / 7.3.2 with fpc 2.4.4 / recent fixes 2.6 / recent trunk stabs dwarf dwarf3 (only trunk + gdb 7.3.2) the result: - all combinations of gdb and fpc using stabs got the corr

Re: [fpc-devel] Unicode support (yet again)

On 15/09/2011 19:36, Hans-Peter Diettrich wrote: Martin schrieb: On 15/09/2011 10:38, Michael Schnell wrote: On 09/15/2011 11:06 AM, Graeme Geldenhuys wrote: and to show you AGAIN how flawed your "direct index access to a character" example is. It's not "my" intend

Re: [fpc-devel] Unicode support (yet again)

On 15/09/2011 19:52, Hans-Peter Diettrich wrote: Graeme Geldenhuys schrieb: On 14/09/2011 19:17, Hans-Peter Diettrich wrote: How many users will have to deal with chars outside the Unicode BMP? Any app that loads a text from disk. it can never know what the text contains. __

Re: [fpc-devel] Unicode support (yet again)

On 16/09/2011 00:03, cobines wrote: 2011/9/15 Hans-Peter Diettrich: cobines schrieb: When doing: MyChar := MyString[1] appropriate function retrieves first unicode character, regardless of encoding. This is just wrong :-( MyString[1] accesses the first element of the *physical* character arr

Re: [fpc-devel] Unicode support (yet again)

On 16/09/2011 02:49, Hans-Peter Diettrich wrote: Martin schrieb: On 15/09/2011 19:52, Hans-Peter Diettrich wrote: Graeme Geldenhuys schrieb: On 14/09/2011 19:17, Hans-Peter Diettrich wrote: How many users will have to deal with chars outside the Unicode BMP? Any app that loads a text from

Re: the feature request, that started the discussion [Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dw

On 16/09/2011 16:05, Joost van der Sluis wrote: On Wed, 2011-09-14 at 10:29 +0100, Martin wrote: So some points, that I would like to know: 1) I believe the general idea, of making a property Counter: Integer read GetCounter be encoded as a function of the object( in the same way as

Re: the feature request, that started the discussion [Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwa

contradiction with 1. I guess Martin means that dwarf3 data must allow gdb (or any other reader) to differentiate whether the property is "implemented" by a getter or a field. Actually, the getter/field will be seen by the fact that the preoprty will appear as field or function. eg a ptype

[fpc-devel] -gh lineinfo or also infodwrf?

In the doc it says at http://www.freepascal.org/docs-html/user/usersu15.html#x38-450005.1.4 -gl Use the lineinfo unit (see Unit Reference ). (Produces file name/line number information if the program exits due to an error.)

[fpc-devel] -gl and -gh

Is it possible that using -gl before -gh on the commandline (" -gl -gh ") => causes heaptrace to fail? Maybe because then lineinfo is used first, and uses the default mem manager? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.f

[fpc-devel] which compile cmmand line switches imply debug info?

Before I go and test each of them myself, maybe someone already has the answer? if using swithches like -gl (lineinfo) -gh (heaptrc) -gv (valgrind) -pg (GProf) do they automatically add debug info (stabs if no other specified)? or do only the -g? do that For lineinfo, I assume yes, sin

Re: [fpc-devel] which compile cmmand line switches imply debug info?

On 17/09/2011 14:36, Florian Klämpfl wrote: Am 17.09.2011 11:58, schrieb Martin: For lineinfo, I assume yes, since the unit has nothing to report on if not. heaptrc could live without, couldn't it? Yes, in this case just add the heaptrc unit to the uses clause. Does that mean -gh doe

Re: [fpc-devel] which compile cmmand line switches imply debug info?

On 17/09/2011 14:43, Jonas Maebe wrote: On 17 Sep 2011, at 15:39, Martin wrote: Does that mean -gh does add debug info? As the compiler help specifies, -g enables debug information. -gh is the same as -g -gh. You can use -g-h to enable heaptrc without debug information. thanks for the tip

[fpc-devel] crash in heaptrc

ash should happen. Depends - if lazarus indeed trashed structures belonging to heaptrc => well then it may happen - if lazarus got memory from somewhere else (which could be the case here) then it shouldn't happen. I haven't got the insight i

Re: [fpc-devel] crash in heaptrc

On 17/09/2011 19:15, Jonas Maebe wrote: On 17 Sep 2011, at 16:41, Martin wrote: It happens when the lazarus IDE is compiled with both -gh and -gc -gc is a fairly flaky option and it can only be used if your entire application only consists of FPC code. In general, I would strongly

[fpc-devel] more question on -g commandline switches / -gv valgind

Trying to improve the lazarus user-interface for selecting what debug info to generate, I try to understand the relations between settings. (as for example, indicating to the user, that -gl causes the same debug info than -g does) Valgrind requires debug info too so -g-v is nonsnes.. It also un

Re: [fpc-devel] "referenced properties" vs "value properties"

On 20/09/2011 13:21, Skybuck Flying wrote: The problem with properties currently is that it does not allow partial modification of records or arrays, when a property is of type record or array it's a everything or nothing situation, either the entire record/array is overwritten/returned or noth

Re: [fpc-devel] Calling virtual methods in GDB

On 27/09/2011 16:58, Joost van der Sluis wrote: Hi all, I've just committed a fix (r19253) which makes it possible to call virtual methods within GDB. (Or other Dwarf-debuggers, when they support that properly) Only problem is that when GDB is in Pascal mode, it won't work. I have written a pat

Re: [fpc-devel] alignment warnings

On 30/09/2011 10:44, Henry Vermaak wrote: Hi list Thinking more about the alignment problems on arm and elsewhere, I was wondering how hard it would be to implement something like gcc's -Wcast-align. Here's a description from the man page: Warn whenever a pointer is cast such that the requi

Re: [fpc-devel] New Windows gdb-binary

blems on i386 regarding the calling conventions remain, and there seems to be some problems still with overridden functions) Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Will do (weekend just ahead, what a coincidence... :) ) Oh, you can download it

Re: [fpc-devel] New Windows gdb-binary

On 30/09/2011 15:45, Joost van der Sluis wrote: On Fri, 2011-09-30 at 21:47 +0800, Paul Ishenin wrote: 30.09.2011 21:02, Joost van der Sluis wrote: Hi all, For all those who are interested in new debug-features of fpc and gdb, I have cross-compiled a gdb-executable for Windows. It's based on

Re: [fpc-devel] New Windows gdb-binary

On 30/09/2011 16:22, Joost van der Sluis wrote: On Fri, 2011-09-30 at 15:54 +0100, Martin wrote: Now reading it again, does it mean: 1) gdb can (magically?) get the return value of a function/method, but WITHOUT calling/invoking the function (e.g. for properties) 2) gdb can "evaluate"

Re: [fpc-devel] New Windows gdb-binary

On 30/09/2011 14:02, Joost van der Sluis wrote: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip It crashes when -Xe (external linker) was used. Also crashes

Re: [fpc-devel] New Windows gdb-binary

On 30/09/2011 23:23, Martin wrote: On 30/09/2011 14:02, Joost van der Sluis wrote: Please test this gdb-version, and tell me about your experiences. Especially Martin. ;) Oh, you can download it here: http://www.lazarussupport.com/gdb_lazarssupport_20110930.zip It crashes when -Xe

[fpc-devel] building fpc / fpmake and multicore cpu ?

I noticed, when I build fpc, then I get cpu usage between 70% and 100%. So it appears that both cores of my pentium are used. But when a package is compiled using fpmake, then it drops to 50%, so apparently only one core is used? Is that correct? Does the old Makefile driven compilation use b

Re: [fpc-devel] New Windows gdb-binary

On 02/10/2011 14:05, Joost van der Sluis wrote: On Sat, 2011-10-01 at 09:08 +0200, Joost van der Sluis wrote: On Sat, 2011-10-01 at 01:05 +0100, Martin wrote: Ok, seems to have big issues with strings in fields. Ow, man.. That's probably difficult again. While evaluating values, it doe

Re: [fpc-devel] New Windows gdb-binary

On 02/10/2011 15:02, Joost van der Sluis wrote: btw: I could not reproduce the external-linker and stabs crashes. Can you give me some more info? Hm, I have to check what version of the external linker I have. C:\FPC\trunk\bin\i386-win32>ld.exe -v GNU ld version 2.16.91 20050827 Maybe time to

[fpc-devel] massive slowdown of my code with fpc trunk

If I run the attached project compiled with fpc trunk (maybe a week old), it runs 5 times slower than when compiled with fpc 2.4.4 First question, can someone else reproduce that? I couldn't find much difference in the output of -al (except some naming convention), so I wonder.. project1.rar

[fpc-devel] fpc trunk (today) just stops with "Fatal: Compilation aborted"

Trying to compile lazarus with trunk fpc: Any ideas? make.exe[2]: Entering directory `C:/lazarus_latest/ide' C:/FPC/trunk_gw/bin/i386-win32/fpc.exe -gl -dlclwin32 -Fu../lcl/units/i386-win32 -Fu../lcl/units/i386-win32/win32 -Fu../components/codetools /units/i386-win32 -Fu../components/lazutils/

Re: [fpc-devel] fpc trunk (today) just stops with "Fatal: Compilation aborted"

exitcode (normal if you did not specify a source file to be compiled) =thread-exited,id="1",group-id="i1" =thread-group-exited,id="i1",exit-code="01" *stopped,reason="exited",exit-code="01" (gdb) bt &"bt\n" &"No stack.\n

[fpc-devel] limited -gc ?

-gc, is apparently only useful in very limited scenarios, such as applications, that have no interaction with the OS at all, or can otherwise gurantee, never to access any memory that was returned by (and therefore allocated by) the OS. An LCL app can not guarantee that... Yet what I am looki

Re: [fpc-devel] limited -gc ?

On 09/10/2011 21:44, Jonas Maebe wrote: On 09 Oct 2011, at 22:34, Martin wrote: Every class or dyn array should be in a block of memory allocated by the fpc heap mgr (probably even always at the start (or fixed offset) of such a block). That is incorrect: classes can override newinstance and

[fpc-devel] new string - question on usage

With fpc trunk strings are now codepage aware. I currently face the issue, that lot's of old code just use "var foo: string". or sometimes explicit "ansistring". No idea what encoding that stores, put it does not seem to be utf8. If I pass such a string (which contains utf8, but seems not to

Re: [fpc-devel] new string - question on usage

On 10/10/2011 21:56, Jonas Maebe wrote: 2- It should have (dont know if currently has) a compiler switch to change the default code page to UTF8 or whatever, so all variables with type String will map to UTF8String. I doubt that such a feature will be added. If you want that, declare your own

Re: [fpc-devel] new string - question on usage

On 10/10/2011 22:36, Jonas Maebe wrote: On 10 Oct 2011, at 23:11, Martin wrote: On 10/10/2011 21:56, Jonas Maebe wrote: 2- It should have (dont know if currently has) a compiler switch to change the default code page to UTF8 or whatever, so all variables with type String will map to

Re: [fpc-devel] new string - question on usage

On 10/10/2011 23:19, Paul Ishenin wrote: 11.10.2011 6:10, Martin wrote: I wasn't askin for changing the default. just for how to do procedure foo(x: utf8string); begin end; var a: string; //ansistring, but contains already utf8 foo(a); // do not convert use foo(x: rawbytestring) Not

[fpc-devel] new strings, rawbyte type, but what about "raw" encoding

Just out of curiosity, and without even being sure, if a real use case for something like this ever exists With the new strings, the encoding is part of the data, not the type. However most types force a specific encoding, therefore conversion occurs. rawbytestring does not force a specific

Re: [fpc-devel] new strings, rawbyte type, but what about "raw" encoding

On 11/10/2011 02:46, Marco van de Voort wrote: In our previous episode, Martin said: Now my question. Is there (or going to be) an encoding, that is "unknown" and will never be converted. but can be assigned to any of the types? Afaik, there is no such thing in Delphi. Slight

[fpc-devel] stabs on Mac / relocation issue?

Is there a known issue on Mac? The following was observed on 2 different 32 bit Mac: compiling from lazarus tests/lazutils/testunicode.lpi with -gs / also entire LCL compiled with -gs / standard fpc 2.4.4 installation (I would assume that does not have dwarf? but I do not know) info line "/

Re: [fpc-devel] stabs on Mac / relocation issue?

On 13/10/2011 09:37, Jonas Maebe wrote: Is there a table somewhere about which debug info types are default in each operating system? No, and such table will not be made because it's an implementation detail. If you require a particular debug information format, specify it. Anything else wi

[fpc-devel] maximum number of params to function? and misleading error>

Is there a maximum number of params that a function can take? Before the compiler gives the error: WatchesPrg.pas(274,3) Error: Wrong number of parameters specified for call to "FooFunc" Despite, they are the same number? that is, I f I comment out one param on both sides (calling, and declar

[fpc-devel] -Oodfa

Florian wrote at http://bugs.freepascal.org/view.php?id=20907 FPC has a good enough dfa, however it is only activated when compiling with -Oodfa: c:\fpc\svn\compiler>fpc ..\tw20907 -vw -Oodfa Is that documented somewhere ? Is that production read or beta? fpc -i only lists: Supported Optim

[fpc-devel] property cam access private symbol from class in other unit

Only tested with 2.4.4; so if changed in 2.6 in unit2 TFoo = class(TObject) private FBar: integer; public property Bar: integer read FBar write FBar; end; which means in unit1, it is not allowed to access TFoo.FBar But it can be done: property Num: Integer read FFoo

Re: [fpc-devel] property cam access private symbol from class in other unit

On 04/01/2012 17:27, Jonas Maebe wrote: On 04 Jan 2012, at 18:13, Martin wrote: Only tested with 2.4.4; so if changed in 2.6 http://wiki.freepascal.org/User_Changes_2.6.0#Inaccessible_symbols_and_properties I just upgraded to 2.6.0 - It still compiles (recompiling fpc trunk now, may

Re: [fpc-devel] property cam access private symbol from class in other unit

On 04/01/2012 20:01, Pete Cervasio wrote: On Wednesday, January 04, 2012 01:26:52 pm Martin wrote: > TForm1 = class(TForm) > public > FFoo: TFoo; > property Num: Integer read FFoo.FBar; > end; Just a 'for your info' note: Kylix doesn't allow the above. No

[fpc-devel] issue in heaptrc?

I ve been playing around with -gc and I found something suspect in heaptrc procedure CheckPointer(p : pointer); [public, alias : 'FPC_CHECKPOINTER']; "p" is a pointer, that should be somewhere *inside* an allocated block of mem pp:=loc_info^.heap_mem_root; while pp<>nil do begin {

Re: [fpc-devel] issue in heaptrc?

On 26/01/2012 13:56, Pierre Free Pascal wrote: Yes, you are right... I just committed a fix (together with multi-threaded windows executable support in trunk) If you have svn trunk, could you check that revision 20181 fixes the problem you report? Thanks in advance, It looks right from the

[fpc-devel] contains

Any body an idea, in whic context "contains" may be a keyword? Original Message Subject:synedit questiions Date: Mon, 30 Jan 2012 12:51:00 +0400 From: Anton Reply-To: A.S. Organisation: [AST] To: Martin Hello, Martin! I have some quest

[fpc-devel] getting error, after publishing property

I have some code, and an error, that I can not explain (fpc 2.4.4 and 2.6) the base class defines public property Editor: TCustomSynEdit read GetEditor write SetEditor; in the inherited class, I can access Editor (of course I can) but I add published property Editor: TCustomSynEdit

Re: [fpc-devel] getting error, after publishing property

On 17/02/2012 15:19, Sven Barth wrote: Am 17.02.2012 16:15, schrieb Martin: I have some code, and an error, that I can not explain (fpc 2.4.4 and 2.6) the base class defines public property Editor: TCustomSynEdit read GetEditor write SetEditor; in the inherited class, I can access Editor (of

[fpc-devel] BackTraceStrFunc / reset to system handler

In light of a recent mail thread on the topic and http://bugs.freepascal.org/view.php?id=21370 From: rtl\inc\lnfodwrf.pp function DwarfBackTraceStr(addr : Pointer) : shortstring; var ... Success : boolean; begin { reset to prevent infinite recursion if problems inside the code } Success:

[fpc-devel] procedure declaration forward, to other unit ?

If I have a class TFoo in UnitFoo, then I can : unit UnitOther; uses UnitFoo; interface type TFoo = UnitFoo.TFoo; Now people who use UnitOther, can use TFoo, but do nut need to explicitly use UnitFoo. I am looking for a way to do that with procedures. Of course I can declare them an

[fpc-devel] global property, with getter in other unit

Defining a property in the interface section (outside a class), that refers to methods in another unit, gives an *unexpected* error. It may well be not allowed and then should give an error, but the right error in the right place. Btw, only tested with 2.4.4, apologies if that is fixed in 2.6.

Re: [fpc-devel] global property, with getter in other unit

On 28/02/2012 00:46, Paul Ishenin wrote: 28.02.2012 3:01, Martin пишет: Defining a property in the interface section (outside a class), that refers to methods in another unit, gives an *unexpected* error. It may well be not allowed and then should give an error, but the right error in the right

Re: [fpc-devel] global property, with getter in other unit

On 29/02/2012 01:40, Paul Ishenin wrote: 28.02.2012 9:11, Martin пишет: Attached. It needed 3 units, accessing Foo in the same unit, in which it is declared (unit2) compiles (not tested if it runs...) You found some bug in the compiler. Property can only be declared inside a structure but

Re: [fpc-devel] global property, with getter in other unit

On 29/02/2012 02:20, Martin wrote: On 29/02/2012 01:40, Paul Ishenin wrote: 28.02.2012 9:11, Martin пишет: Attached. It needed 3 units, accessing Foo in the same unit, in which it is declared (unit2) compiles (not tested if it runs...) You found some bug in the compiler. Property can

[fpc-devel] FreeNotification and opRemove

I found a behaviour, of which I am not sure, if it is intended. Maybe someone can comment My understanding is that FreeNotification are *always* set up bi-directional ? At least C1.FreeNotification(C2); will set up for C1 to inform C2, and for C2 to inform C1 whichever is destroyed first to

Re: [fpc-devel] FreeNotification and opRemove

Further more: the program below, does not crash in delphi (turbo delphi) On 08/03/2012 09:56, Martin wrote: I found a behaviour, of which I am not sure, if it is intended. Maybe someone can comment My understanding is that FreeNotification are *always* set up bi-directional ? At least C1

Re: [fpc-devel] FreeNotification and opRemove

On 08/03/2012 13:08, michael.vancann...@wisa.be wrote: On Thu, 8 Mar 2012, Martin wrote: Further more: the program below, does not crash in delphi (turbo delphi) I also noticed. I suspect the problem is the owner; If it gets a free notification, it should pass it to all the children. I

Re: [fpc-devel] FreeNotification and opRemove

On 08/03/2012 13:34, Martin wrote: On 08/03/2012 13:08, michael.vancann...@wisa.be wrote: On Thu, 8 Mar 2012, Martin wrote: Further more: the program below, does not crash in delphi (turbo delphi) I also noticed. I suspect the problem is the owner; If it gets a free notification, it

Re: [fpc-devel] FreeNotification and opRemove

On 08/03/2012 13:44, Martin wrote: In the following code, I thing is the problem: Procedure TComponent.Notification(AComponent: TComponent; Operation: TOperation); Var Runner : Longint; begin If (Operation=opRemove) and Assigned(FFreeNotifies) then begin FFreeNotifies.Remove

Re: [fpc-devel] FreeNotification and opRemove

On 08/03/2012 13:34, Martin wrote: On 08/03/2012 13:08, michael.vancann...@wisa.be wrote: On Thu, 8 Mar 2012, Martin wrote: Further more: the program below, does not crash in delphi (turbo delphi) I also noticed. I suspect the problem is the owner; If it gets a free notification, it

[fpc-devel] class section (public, private) in debug info

Is this an FPC issue or gdb? Tested with fpc 2.6 / gdb 7.3-2 , win 32 Stabs, seems to have the right sections for fields. Stabs also shows methods, but they seem to be without any info about class sections Dwarf (see below) everything seems to be public: Dwarf does not seem to show methods >>

[fpc-devel] preserve case in debug info

I know -gp works for stabs. Is there a way for dwarf too? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] class section (public, private) in debug info

On 20/03/2012 07:41, Paul Ishenin wrote: 20.03.2012 15:39, Graeme Geldenhuys написал: Maybe I'm not understanding this correctly, but why would you want "visibility restrictions" on debug information? Surely when debugging, you want access to ALL data - thus public visibility across the board se

[fpc-devel] trunk no longer compiles with -Cr

on Win 32 Compiling .\winunits-base\src\typelib.pas typelib.pas(371,71) Hint: Local variable "Handle" does not seem to be initialized typelib.pas(493,33) Hint: Local variable "sl" does not seem to be initialized typelib.pas(562,48) Hint: Local variable "sMethodName" does not seem to be initia

Re: RE : [fpc-devel] trunk no longer compiles with -Cr

On 20/03/2012 12:55, Ludo Brands wrote: typelib.pas(1353,48) Error: range check error while evaluating constants (-1 must be between 0 and 4294967295) Can you raise a mantis issue? I'll fix this. According to msdn http://msdn.microsoft.com/en-us/library/cc237755%28v=prot.10%29.aspx the function

[fpc-devel] minor issue building fpc

Not sure if that is a known issue. Or considered an issue at all. But on windows, if you specify the INSTALL_PREFIX with a trailing "\" (which afaik is a normal way to specify a directory), install will fail. make.exe install INSTALL_PREFIX=c:\FPC\tag_2_6_0\ FPC=C:\fpc\SVN\tag_2_6_0\comp

Re: [fpc-devel] Strange Problem!

On 25/04/2012 21:11, Amir wrote: I am not sure what you mean be "your program is not valid". I am initializing Result. Modify its content and ... I already observed that if I use either shortstring or use indices to modify Result, this problem does not occur. But still I can't see what caus

Re: [fpc-devel] Class field reordering

On 14/07/2012 20:46, Jonas Maebe wrote: That may actually lead to quite some troubles: if someone recompiles the RTL without optimizations, then your class crackers also have to change that setting. And there's no way to detect how the RTL (or in general: units containing classes you are "crac

Re: [fpc-devel] Re: Class field reordering

On 21/07/2012 16:55, Ivanko B wrote: The problem now is that cracker classes can't be used in future anymore because of the new class field ordering optimisation, so I dared to ask. So, is it possible to design the new feature in such way that to have an option to proceed using cracker c

[fpc-devel] potential issue with symbol info generated by fpc

http://forum.lazarus.freepascal.org/index.php/topic,17766.0.html I do not know if it is fpc or gdb. But something seems to have changed (or change forward and back) in fpc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freep

[fpc-devel] Does FPC optimize unused parameters ?

Out of curiosity. Is there an optimization like this (or is it possible? procedure Foo(a:String; B: Integer); inline; // inline is optional begin // EMPTY end; This is a plain procedure, not a method, not overloaded, not virtual. And the parameters are both not used in the procedure (But obvi

Re: [fpc-devel] Does FPC optimize unused parameters ?

On 08/08/2012 15:37, Jonas Maebe wrote: [removing calculation/load of unused parameters] No. I assumed that... (or is it possible? After the body of the called routine has been parsed, it would be possible in theory (with indeed all the caveats the compiler would have to take care of such

  1   2   3   4   5   6   7   8   9   10   >