[fpc-devel] merge request
Hi, I get a compilation error in the compiler when creating a win32 to arm-wince crosscompiler with fpc 2.5.1: cgcpu.pas(2087,88) Error: Identifier not found pasbool Can http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/pasboolxx/compiler/arm/cgcpu.pas?r1=17847r2=17846pathrev=17847 be merged to trunk? Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] volatile variables
A similar discussion is going on in Lazarus-develop, but this obviously is a compiler question. In C, there is the volatile keyword that ensures that after the code sequence enters the next C instruction after that which modified this variable, another thread sees the correct state of the variable. This is ensured by not caching the value in registers and on SMP systems additionally by low level stuff like memory barriers. Of course this does not protect concurrent read-modify-write accesses (same need to be protected by low level atomic instructions or MUTEX and friend). For variables not defined as volatile, (e.g.) pthread_mutex (and similar stuff on Windows) can be used to protect them. AFAIK, in Pascal all Global (Static) variables are considered to be handled as volatile, so no problem here (other than handling all of them them as volatiles might decrease performance slightly). But what about variables on the heap ? If class instance variables or - say - a liked list done with records created by new are accessed by multiple threads, how can said consistency be enforced ? Even if you use a critical section to do the protection, this does not help if the compiler decides to cache the variable in a register while entering or exiting the critical section. But even without dedicated protection, a volatile variable should be able to be be monitored from another thread. Can this be enforced in Pascal for help variables ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language idea:Unified types(assignmentsize-compatible types). (Automated check)
Here is a little idea for an automated check or so, to warn if something odd
is happening or so ;) :):
Assert( SizeOf(byte) = 1, 'SizeOf(byte)(' + IntToStr(SizeOf(byte)) + ') =
1' );
Assert( SizeOf(word) = 2, 'SizeOf(word)(' + IntToStr(SizeOf(word)) + ') =
2' );
Assert( SizeOf(longword) = 4, 'SizeOf(longword)(' +
IntToStr(SizeOf(longword)) + ') = 4' );
Assert( SizeOf(uint64) = 8, 'SizeOf(uint64)(' + IntToStr(SizeOf(uint64)) +
') = 8' );
Assert( SizeOf(shortint) = 1, 'SizeOf(shortint)(' +
IntToStr(SizeOf(shortint)) + ') = 1' );
Assert( SizeOf(smallint) = 2, 'SizeOf(smallint)(' +
IntToStr(SizeOf(smallint)) + ') = 2' );
Assert( SizeOf(integer) = 4, 'SizeOf(integer)(' + IntToStr(SizeOf(integer))
+ ') = 4' );
Assert( SizeOf(int64) = 8, 'SizeOf(int64)(' + IntToStr(SizeOf(int64)) + ') =
8' );
Code is untested but should work ! ;)
Bye,
Skybuck.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Compiling FPC with DEBUG
Hi, I compile FPC with success using my tutorial: http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29 Questions: 1- How can I compile all packages with DEBUG option? 2- How can I compile just one package, eg fcl-xml, with DEBUG option? Thanks, Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 01:20 PM, Henry Vermaak wrote: Operations on volatile variables are not atomic, That is of course known. nor do they establish a proper happens-before relationship for threading. I see. So maybe part of my question is invalid. But as pthread_mutex (and the appropriate Windows stuff) contains a memory barrier, same does enforce memory ordering even in an SMP environment, regarding cache operations and with CPUs that do on-the fly reordering. So, regarding C, I understand that (even in a single CPU environment): If all accesses to a variable are protected by a MUTEX, multiple threads will use the variable as expected, only if it is defined as volatile. Otherwise is might be cached in registers and one thread's writing to (i C code but not compiled that way) it might be unnoticed by the other thread. Now how is the volatile state defined in Pascal and how can a heap variable be defined to be handled as volatile ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell mschn...@lumino.de wrote: For variables not defined as volatile, (e.g.) pthread_mutex (and similar stuff on Windows) can be used to protect them. A mutex may be able to atomically block access because of its own memory barrier, but I would suggest that employing such a technique on multi-core systems will not ensure an accurate value. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28 Jun 2011, at 14:58, Andrew Brunner wrote: On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell mschn...@lumino.de wrote: For variables not defined as volatile, (e.g.) pthread_mutex (and similar stuff on Windows) can be used to protect them. A mutex may be able to atomically block access because of its own memory barrier, but I would suggest that employing such a technique on multi-core systems will not ensure an accurate value. pthread_mutex() does guarantee that. I don't know about the Windows equivalents. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 8:00 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 28 Jun 2011, at 14:58, Andrew Brunner wrote: On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell mschn...@lumino.de wrote: For variables not defined as volatile, (e.g.) pthread_mutex (and similar stuff on Windows) can be used to protect them. A mutex may be able to atomically block access because of its own memory barrier, but I would suggest that employing such a technique on multi-core systems will not ensure an accurate value. pthread_mutex() does guarantee that. I don't know about the Windows equivalents. Specification just describes standard mutex. What makes pthreads specification different to include ordering? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28 Jun 2011, at 15:05, Andrew Brunner wrote: On Tue, Jun 28, 2011 at 8:00 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 28 Jun 2011, at 14:58, Andrew Brunner wrote: A mutex may be able to atomically block access because of its own memory barrier, but I would suggest that employing such a technique on multi-core systems will not ensure an accurate value. pthread_mutex() does guarantee that. I don't know about the Windows equivalents. Specification just describes standard mutex. What makes pthreads specification different to include ordering? http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ V1_chap04.html (point 4.11) Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28/06/11 14:00, Jonas Maebe wrote: On 28 Jun 2011, at 14:58, Andrew Brunner wrote: On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell mschn...@lumino.de wrote: For variables not defined as volatile, (e.g.) pthread_mutex (and similar stuff on Windows) can be used to protect them. A mutex may be able to atomically block access because of its own memory barrier, but I would suggest that employing such a technique on multi-core systems will not ensure an accurate value. pthread_mutex() does guarantee that. I don't know about the Windows equivalents. I've found this earlier: http://msdn.microsoft.com/en-us/library/ms686355%28v=VS.85%29.aspx Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28 Jun 2011, at 14:32, Michael Schnell wrote: So, regarding C, I understand that (even in a single CPU environment): If all accesses to a variable are protected by a MUTEX, multiple threads will use the variable as expected, only if it is defined as volatile. Otherwise is might be cached in registers and one thread's writing to (i C code but not compiled that way) it might be unnoticed by the other thread. The C (or Pascal) compiler has no idea whether or not the global variable will be accessed by the pthread_mutex_lock()/unlock() function. As a result, it will never cache it in a register across function calls, and the call to the mutex function by itself guarantees that the variable's value will be written back. So you don't need volatile. Even if it's a local variable you don't need it, because as soon as you take the address of a local variable and it can escape the current function (and hence the current thread), the compiler again has to assume that any called function may modify it via an indirect access. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 02:58 PM, Andrew Brunner wrote: A mutex may be able to atomically block access because of its own memory barrier, but I would suggest that employing such a technique on multi-core systems will not ensure an accurate value. If this is true, how can any multithreaded be done ? Only the ordering decision inside vs outside of the critical section is necessary for threaded user application. If both Enter and Leave do a full fence barrier, I suppose we are safe. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html (point 4.11) Nope. Nothing about order - just access - and that is entirely on the application level - not system. 1.) Code execution on die is not controlled by pthreads implemention - as it is unaware at that level. 2.) Blocking access as described in 4.11 does not address execution order. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 8:16 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: The C (or Pascal) compiler has no idea whether or not the global variable will be accessed by the pthread_mutex_lock()/unlock() function. As a result, it will never cache it in a register across function calls, and the call to the mutex function by itself guarantees that the variable's value will be written back. Agreed. And you can make such access atomic. Getting developers to chose the right tool for the job is the key here. But understanding the core issues (pun intented ;-) is the key. So you don't need volatile. Even if it's a local variable you don't need it, because as soon as you take the address of a local variable and it can escape the current function (and hence the current thread), the compiler again has to assume that any called function may modify it via an indirect access. There is no problem no need for volatile variables. Compare and Swap or Interlocked mechanisms will solve any problems. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 03:00 PM, Jonas Maebe wrote: . I don't know about the Windows equivalents. see http://msdn.microsoft.com/en-us/library/ms686355%28v=VS.85%29.aspx ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28 Jun 2011, at 15:20, Andrew Brunner wrote: On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html (point 4.11) Nope. Nothing about order - just access - and that is entirely on the application level - not system. 1.) Code execution on die is not controlled by pthreads implemention - as it is unaware at that level. I have no idea what you mean by this. What would code execution off die be as opposed to code execution on die? 2.) Blocking access as described in 4.11 does not address execution order. It does guarantee that if T1 locks the mutex, changes the value, unlocks the mutex and then T2 acquires the mutex (either on another cpu or not is irrelevant), then T2 will observe strict memory ordering with respect to T1 as far as this memory location is concerned (i.e., it will see any changes to that memory location performed by T1 that were protected by the mutex). If by execution ordering you mean that there is no guarantee regarding which thread will acquire the mutex first, then that's true, but synchonrization races are unrelated to memory ordering issues. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 8:28 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: 1.) Code execution on die is not controlled by pthreads implemention - as it is unaware at that level. I have no idea what you mean by this. What would code execution off die be as opposed to code execution on die? on die image was meant to take you to the code on the actual core being executed. That is to say the core itself is ignorant of what just executed before and will just take the code and execute it. 2.) Blocking access as described in 4.11 does not address execution order. It does guarantee that if T1 locks the mutex, changes the value, unlocks the mutex and then T2 acquires the mutex (either on another cpu or not is irrelevant), then T2 will observe strict memory ordering with respect to T1 as far as this memory location is concerned (i.e., it will see any changes to that memory location performed by T1 that were protected by the mutex). Sort of right. 6 core system. Core 1 locks code block. Code block should still use interlocked statements to make memory assignments so that when Core 1 releases lock - Core 2 can have a real-time image of variable. Otherwise Core 2 may see a stale copy of the variable. If by execution ordering you mean that there is no guarantee regarding which thread will acquire the mutex first, then that's true, but synchonrization races are unrelated to memory ordering issues. Don't bother looking that deep. The topic the poster raised is about variable volatility with respect to thread safe code. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28 Jun 2011, at 15:39, Andrew Brunner wrote: On Tue, Jun 28, 2011 at 8:28 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: 1.) Code execution on die is not controlled by pthreads implemention - as it is unaware at that level. I have no idea what you mean by this. What would code execution off die be as opposed to code execution on die? on die image was meant to take you to the code on the actual core being executed. That is to say the core itself is ignorant of what just executed before and will just take the code and execute it. That's why libpthread includes memory barriers. It does guarantee that if T1 locks the mutex, changes the value, unlocks the mutex and then T2 acquires the mutex (either on another cpu or not is irrelevant), then T2 will observe strict memory ordering with respect to T1 as far as this memory location is concerned (i.e., it will see any changes to that memory location performed by T1 that were protected by the mutex). Sort of right. 6 core system. Core 1 locks code block. Code block should still use interlocked statements to make memory assignments so that when Core 1 releases lock - Core 2 can have a real-time image of variable. Otherwise Core 2 may see a stale copy of the variable. No, that is impossible. That's the whole point of using libraries such as libpthread. They abstract such issues away. Using atomic operations inside mutex sections only slows down your program unnecessarily (unless you also access the target memory location from code not guarded by that mutex, and also use atomic operations in those alternate cases -- or if you are using a synchronization primitive from a library that does not observe the same semantics as libpthread, but that would be a really strange design decision). If what you write above would be true, almost no program using libpthread for synchronization would consistently work on multi-core systems. How many programs do you know that exclusively use atomic operations to access shared memory locations inside code regions guarded by a pthread_mutex? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 03:16 PM, Jonas Maebe wrote:
The C (or Pascal) compiler has no idea whether or not the global
variable will be accessed by the pthread_mutex_lock()/unlock()
function. As a result, it will never cache it in a register across
function calls, and the call to the mutex function by itself
guarantees that the variable's value will be written back.
If in C you do
static int x;
void play_with_x(void) {
for (i=1; i0; i--) {
x += 1;
};
x = 0;
};
the compiler will see that x is just defined to be 0 in the end and
optimize out thge complete loop.
But if you do the same with
volatile static int x;
the code will stay and another thread can watch x growing in a time
sharing system.
I believe that inserting some ptherad_mutex... calls will not force the
compiler to bother about some intermediate values of a non volatile
variable.
I believe that with FPC global variables are assumed to be volatile and
not optimized away or cashed in registers. But what about heap-variables ?
Even if it's a local variable you don't need it,
Of course not as they can't be accessed by anybody but the running
thread anyway.
the compiler again has to assume that any called function may modify
it via an indirect access.
... if same gets the address (which of course is possible with a global
variable)
Thus true for global variables, not necessary true for static variables
as they can't be accessed by a function defined in another module (I
don't know whether the C compiler makes a difference)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 03:23 PM, Andrew Brunner wrote: Getting developers to chose the right tool for the job is the key here. Regarding normal user application there is only one option: Posix. Ans same happily is encapsulated in the RTL/LCL for FPC/Lazarus programmers. Advanced (non-portable) programming of course can be necessary in certain projects. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 03:23 PM, Andrew Brunner wrote: There is no problem no need for volatile variables. Compare and Swap or Interlocked mechanisms will solve any problems. volatile is a directive to the compiler on how to handle a variable. Variables that are not handled by the compiler but handled by non portable low level assembler functions of course are volatile on their own account. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28/06/11 14:20, Andrew Brunner wrote: On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebejonas.ma...@elis.ugent.be wrote: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html (point 4.11) Nope. Nothing about order - just access - and that is entirely on the application level - not system. 1.) Code execution on die is not controlled by pthreads implemention - as it is unaware at that level. Of course it is. They issue a hardware memory barrier. This stops the cpu from reordering operations. How do you think anything using pthreads will work if they didn't? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28/06/11 14:23, Andrew Brunner wrote: There is no problem no need for volatile variables. Compare and Swap or Interlocked mechanisms will solve any problems. Nope. You still need to prevent the cpu from reordering instructions with memory barriers. I'm starting to sound like a broken record. If you don't understand this, use the threading primitives provided by your operating system like everyone else. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
No, that is impossible. That's the whole point of using libraries such as libpthread. They abstract such issues away. Using atomic operations inside mutex sections only slows down your program unnecessarily (unless you also access the target memory location from code not guarded by that mutex, and also use atomic operations in those alternate cases -- or if you are using a synchronization primitive from a library that does not observe the same semantics as libpthread, but that would be a really strange design decision). Two issues with what you are suggesting Jonas. Issue 1.) libpthread is just a posix implementation. it does not AUTOMATICALLY resolve issues inherent with present day multi-core memory access with respect to cores. It is by definition a thread implementation that includes atomic locks. Issue 2.) Telling people that it is poor design to exclude posix threads implementation is ignorant. FPC is cross platform. Posix threads specification is mainly to offer windows like threadding to unix/linux flavors. If what you write above would be true, almost no program using libpthread for synchronization would consistently work on multi-core systems. How many programs do you know that exclusively use atomic operations to access shared memory locations inside code regions guarded by a pthread_mutex? Access vs. Order. This is what makes a variable volatile across cores (not threads). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
Of course it is. They issue a hardware memory barrier. This stops the cpu from reordering operations. How do you think anything using pthreads will work if they didn't? Documentation please? If what you are saying is accurate just point me to the documentation? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] volatile variables
Hello FPC, Tuesday, June 28, 2011, 3:39:29 PM, you wrote: AB Sort of right. 6 core system. Core 1 locks code block. Code block AB should still use interlocked statements to make memory assignments so AB that when Core 1 releases lock - Core 2 can have a real-time image of AB variable. Otherwise Core 2 may see a stale copy of the variable. Core 2 should only access those variables using the same lock (critical section) as core 1 or data integrity is not garanteed. Critical sections garantee a full fence, pipe lines as invalidated. The only possible problem is the variable caching in a register, but as stated here the call to the function that perform the critical section forces fpc to store the variables in a register to its memory address and the critical section activity forces the fence ensuring all cores see the same data at the same time. You can not protect a code with a critical section and access the data without using the same critical section, so you can not protect code with a critical section and operate over the data in other thread with interlock operations. This is not threading 101, do not ? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 9:00 AM, Henry Vermaak henry.verm...@gmail.com wrote: On 28/06/11 14:23, Andrew Brunner wrote: There is no problem no need for volatile variables. Compare and Swap or Interlocked mechanisms will solve any problems. Nope. You still need to prevent the cpu from reordering instructions with memory barriers. I'm starting to sound like a broken record. If you don't understand this, use the threading primitives provided by your operating system like everyone else. Henry You've got your list particiapants mixed up. It was me who suggested order is important (at least on the lazarus discussion). And I am am 100% correct. Interlocked / CAS happen in one shot. They don't need barriers. They are protected. I think you have my conversations mixed up. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28/06/11 15:09, Andrew Brunner wrote: Of course it is. They issue a hardware memory barrier. This stops the cpu from reordering operations. How do you think anything using pthreads will work if they didn't? Documentation please? If what you are saying is accurate just point me to the documentation? Jonas already pointed you to it: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11 Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it. Please note the read or modify. If you fail to understand this, you can read the source of a posix threads implementation, e.g. nptl (which is part of libc). Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28 Jun 2011, at 15:54, Michael Schnell wrote:
static int x;
void play_with_x(void) {
for (i=1; i0; i--) {
x += 1;
};
x = 0;
};
the compiler will see that x is just defined to be 0 in the end and
optimize out thge complete loop.
But if you do the same with
volatile static int x;
the code will stay and another thread can watch x growing in a time
sharing system.
I believe that inserting some ptherad_mutex... calls will not force
the compiler to bother about some intermediate values of a non
volatile variable.
You believe wrongly.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
Jonas already pointed you to it: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11 Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it. Please note the read or modify. If you fail to understand this, you can read the source of a posix threads implementation, e.g. nptl (which is part of libc). I honestly don't believe that by the above statement has anything to do with what we're talking about here. And I'm thinking it's because of the two issues. One is threads. One is cores. I think we need to focus to get to the bottom of what we're all trying to say. I have been following and it is completely agreed that thread locks are NOT what we are trying to discuss. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 04:23 PM, Jonas Maebe wrote: On 28 Jun 2011, at 15:54, Michael Schnell wrote: I believe that inserting some ptherad_mutex... calls will not force the compiler to bother about some intermediate values of a non volatile variable. You believe wrongly. As the compiler does not know anything about what pthread_mutex does just the existence of a function call at that location can trigger that it behaves different from the case that no function call is done. And this has been discussed in the other message: If the variable in fact is global the compiler needs to avoid caching it, if it is static and the function is in another module it might still decide to cache it, but you are right: it is not likely that it does make this difference. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 9:23 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On topic, Jonas can you take a few moments to describe how developers can force code execution in order w/o using a third party library? Is there a compiler directive we can use? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 04:31 PM, Andrew Brunner wrote: how developers can force code execution in order w/o using a third party library? Execution in order only makes sense when there is another thread that relies on this order. So if both threads use the same critical section for accessing all variables that an ordering is necessary with, the actual ordering used completely within the critical section in fact is irrelevant as no other thread can get in the way at that point. So the high level Posix interface that is provided as TCriticalSection in the RTL/LCL should be workable (but not high performance). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 9:33 AM, Michael Schnell mschn...@lumino.de wrote: And this has been discussed in the other message: If the variable in fact is global the compiler needs to avoid caching it, if it is static and the function is in another module it might still decide to cache it, but you are right: it is not likely that it does make this difference. Well, I think one issue is that each core has it's own cache. 1.) How can we get the core to not relent and have the code handed off to another core until we're finished? 2.) How can we get the core to have a synchronised copy of a particular variable (aside from CAS)? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 28 Jun 2011, at 16:28, Andrew Brunner wrote: Jonas already pointed you to it: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11 Applications shall ensure that access to any memory location by more than one thread of control (threads or processes) is restricted such that no thread of control can read or modify a memory location while another thread of control may be modifying it. Please note the read or modify. If you fail to understand this, you can read the source of a posix threads implementation, e.g. nptl (which is part of libc). I honestly don't believe that by the above statement has anything to do with what we're talking about here. And I'm thinking it's because of the two issues. One is threads. One is cores. I think we need to focus to get to the bottom of what we're all trying to say. The Posix specification (and the Win32 api documentation referred to in this thread) doesn't care whether all threads are executed by the same or by different cores, and/or whether separate threads are rescheduled to different cores at different time slices. The specified behaviour is guaranteed to be the same under all circumstances exactly because it is defined at the level of threads rather than cores. That's the whole point of having abstractions such as threads and specifying their behaviour. Even if you would create a libpthread implementation that works on top of MPI and which distributes threads over an entire cluster of different machines, then still the same behaviour would have to be guaranteed (because the *threads* have to comply to the specified behaviour, not specifically pipelines, cores, processors, machines, accelerator cards, ...). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 9:43 AM, Michael Schnell mschn...@lumino.de wrote: On 06/28/2011 04:31 PM, Andrew Brunner wrote: how developers can force code execution in order w/o using a third party library? Execution in order only makes sense when there is another thread that relies on this order. Wrong. Sigh... Order of execution is paramount just about everywhere. It can be disastrous if not understood. Remember ***cores!=threads*** people. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 04:38 PM, Andrew Brunner wrote: 1.) How can we get the core to not relent and have the code handed off to another core until we're finished? 2.) How can we get the core to have a synchronised copy of a particular variable (aside from CAS)? I suppose you need to ask these questions the hardware designers at Intel or AMD (or read the appropriate docs). If cache synchronization would not be done (even without forcing it by atomic interlocked instructions or memory barriers) regarding the huge cache provide with modern CPUs a thread would _never_ see what another thread writes into memory. But (unless some kind of atomicness or ordering is required) there are no issues on that behalf. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On 06/28/2011 05:02 PM, Andrew Brunner wrote: Wrong. Sigh... Order of execution is paramount just about everywhere. It can be disastrous if not understood. You still did not give an example Remember ***cores!=threads*** people. Wrong regarding the issue in question (see the message by Jonas). User programs are not supposed to bother about anything beyond threads that are a well defined arch independent paradigm. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
You can stick your head in the sand all you want, just don't run your code on multi-core cpus and expect valid stability - and come back here complaining on how unstable your multi-threaded application is due to FPC design! User programs are not supposed to bother about anything beyond threads that are a well defined arch independent paradigm. Wrong again... Sigh... Think interlocked variables in your code and you will be fine. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, Jun 28, 2011 at 10:17 AM, Michael Schnell mschn...@lumino.de wrote: You still did not give an example Don't take my word. Just look at the wikipedia link I already posted which indicates otherwise. Remember ***cores!=threads*** people. Wrong regarding the issue in question (see the message by Jonas). I'm at a loss for words. So you equate threads to cores? You know what forget it. Don't bother. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, 28 Jun 2011 15:54:35 +0200, Michael Schnell mschn...@lumino.de wrote: But if you do the same with volatile static int x; the code will stay and another thread can watch x growing in a time sharing system. No, it can't. volatile just ensures that accessing the variable results in actual memory accesses. That does not mean cache-coherence, so another core may still see other (as in older) values. I believe that inserting some ptherad_mutex... calls will not force the compiler to bother about some intermediate values of a non volatile variable. Well, then it's probably overly aggressive or buggy. I believe that with FPC global variables are assumed to be volatile and not optimized away or cashed in registers. But what about heap-variables ? They are not volatile, I'd guess. And I don't see the need to assume they are. You would always need proper synchronisation constructs here. Thus true for global variables, not necessary true for static variables as they can't be accessed by a function defined in another module (I don't know whether the C compiler makes a difference) It should not. It can't possibly assume that a call to pthread_...() wouldn't result in a recursive call back to the caller... ;) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, 28 Jun 2011 15:20:22 +0200, Andrew Brunner andrew.t.brun...@gmail.com wrote: On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html (point 4.11) Nope. Nothing about order - just access - and that is entirely on the application level - not system. |synchronize thread execution and also synchronize memory with respect to other threads. How do you interpret synchronise memory with respect to other threads then? Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
Jonas Maebe schrieb: 2.) Blocking access as described in 4.11 does not address execution order. It does guarantee that if T1 locks the mutex, changes the value, unlocks the mutex [...] Can you explain please, to what changes the value applies? I could not find a definition of the mutex struct, to determine whether it contains any user-alterable values. When the value is declared outside the mutex struct, it will be accessible also *without* locking the mutex first. However I can imagine that some mutex derived *class* (TCriticalSection) can have additional fields, that are inaccessible until some code obtains the mutex (similar to TThreadList). Otherwise a mutex cannot protect anything but itself. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
Andrew Brunner schrieb: On Tue, Jun 28, 2011 at 9:23 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On topic, Jonas can you take a few moments to describe how developers can force code execution in order w/o using a third party library? Is there a compiler directive we can use? I think that you should give at least an example, where instruction reordering makes a difference. Neither a compiler nor a processor is allowed to reorder instructions in a way, that breaks the def/use (produce/consume...) chain (see SSA - Single Static Assignment). No library will prevent you from implementing undetectable side-effects, or to use alias. When in this code snippet list.Add(x); i := list.Count; the statements cannot be executed out-of-sequence, or in parallel, then I assume that every subroutine call will disallow to move instructions from after the call to before it. Everything else would be insane. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
Michael Schnell schrieb: Only the ordering decision inside vs outside of the critical section is necessary for threaded user application. If both Enter and Leave do a full fence barrier, I suppose we are safe. Since the condition is only stored *inside* the CS or mutex, no other code will know about it, unless it *explicitly* queries the state of the object. When you have a look at TThreadList.LockList/UnlockList, then you'll see that LockList enters the critical section, and UnlockList leaves it. All code executed in between such two calls is absolutely ignorant of the state of the CS, there is no in/outside. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
28.06.2011 19:42, Hans-Peter Diettrich wrote: Jonas Maebe schrieb: 2.) Blocking access as described in 4.11 does not address execution order. It does guarantee that if T1 locks the mutex, changes the value, unlocks the mutex [...] Can you explain please, to what changes the value applies? To some variable, not explicitly named here, but not to the mutex. I could not find a definition of the mutex struct, to determine whether it contains any user-alterable values. When the value is declared outside the mutex struct, it will be accessible also *without* locking the mutex first. A mutex is usually treated as opaque. It is only used when entering/leaving critical section, not for storing any user-accessible data. However I can imagine that some mutex derived *class* (TCriticalSection) can have additional fields, that are inaccessible until some code obtains the mutex (similar to TThreadList). Otherwise a mutex cannot protect anything but itself. It is responsibility of a programmer to ensure that all accesses to the variable in question is surrounded by proper enter/leave constructs involving some mutex. Such proper constructs are not enforced by pascal language automatically (like say in java), so mistakes are quite possible (and sometimes do happen). Nikolai DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, 28 Jun 2011 20:09:18 +0200, Hans-Peter Diettrich drdiettri...@aol.com wrote: When you have a look at TThreadList.LockList/UnlockList, then you'll see that LockList enters the critical section, and UnlockList leaves it. All code executed in between such two calls is absolutely ignorant of the state of the CS, there is no in/outside. Of course, why should it bother? The call to unlock should ensures whatever memory synchronisation is required. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, 28 Jun 2011 18:11:29 +0200, Hans-Peter Diettrich drdiettri...@aol.com wrote: I think that you should give at least an example, where instruction reordering makes a difference. Neither a compiler nor a processor is allowed to reorder instructions in a way, that breaks the def/use (produce/consume...) chain (see SSA - Single Static Assignment). Well, yes. But multiple processors are actually allowed to do that. That's why the double-lock idiom for Singletons is bound to break on multi-cores. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, 28 Jun 2011 20:34:19 +0200, Nikolai Zhubr n-a-zh...@yandex.ru wrote: involving some mutex. Such proper constructs are not enforced by pascal language automatically (like say in java), so mistakes are quite possible (and sometimes do happen). JFTR, but they aren't /enforced/ in Java, neither. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
At beginning of June I've found the following link on the ReactOS mailing list when they were discussing about memory ordering and volatile as well: http://kernel.org/doc/Documentation/volatile-considered-harmful.txt For those interested the following is the link to the starting discussion: http://www.reactos.org/archives/public/ros-dev/2011-June/014277.html (I hope the mail thread works in the web view as well as in my mail client) Regards, Sven On 28.06.2011 13:14, Michael Schnell wrote: A similar discussion is going on in Lazarus-develop, but this obviously is a compiler question. In C, there is the volatile keyword that ensures that after the code sequence enters the next C instruction after that which modified this variable, another thread sees the correct state of the variable. This is ensured by not caching the value in registers and on SMP systems additionally by low level stuff like memory barriers. Of course this does not protect concurrent read-modify-write accesses (same need to be protected by low level atomic instructions or MUTEX and friend). For variables not defined as volatile, (e.g.) pthread_mutex (and similar stuff on Windows) can be used to protect them. AFAIK, in Pascal all Global (Static) variables are considered to be handled as volatile, so no problem here (other than handling all of them them as volatiles might decrease performance slightly). But what about variables on the heap ? If class instance variables or - say - a liked list done with records created by new are accessed by multiple threads, how can said consistency be enforced ? Even if you use a critical section to do the protection, this does not help if the compiler decides to cache the variable in a register while entering or exiting the critical section. But even without dedicated protection, a volatile variable should be able to be be monitored from another thread. Can this be enforced in Pascal for help variables ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
28.06.2011 22:38, Vinzent Höfler wrote: involving some mutex. Such proper constructs are not enforced by pascal language automatically (like say in java), so mistakes are quite possible (and sometimes do happen). JFTR, but they aren't /enforced/ in Java, neither. Well, ok, I didn't mean that synchronize is enforced, but rather that it is provisioned with such (simple) syntax that enforces some sanity and hides most complications (so that one can not forget to leave the protected block, or try to use some invalid mutex or try to modify the mutex directly etc...) (That said, I'm personally quite happy with pascal though) Nikolai Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
Andrew Brunner schrieb: On Tue, Jun 28, 2011 at 9:43 AM, Michael Schnell mschn...@lumino.de wrote: On 06/28/2011 04:31 PM, Andrew Brunner wrote: how developers can force code execution in order w/o using a third party library? Execution in order only makes sense when there is another thread that relies on this order. Wrong. Sigh... Order of execution is paramount just about everywhere. It can be disastrous if not understood. Remember ***cores!=threads*** people. If your experience is really that chaotic, I think it's worth some deeper investigation. 1) Can one thread be executed on multiple cores, at the same time? If so, shouldn't there exist means (flags...) to tell the OS, that FPC executables are not (yet) ready for such automatic parallelism? 2) When a thread wanders around, from one core to another one, shouldn't be the starting conditions (CPU state, caches) exactly in the state when the thread was stopped on the previous core? Isn't that effect caused by your monitor, that forces the thread into suspended state frequently? You seem to assume that the cache of the previous core may contain some updated data, that was not yet written back into RAM when the thread is resumed on a different core, whose cache happens to contain other values? This really would be a very big problem :-( [So big that I cannot believe that it really exists] 3) When above cache inconsistencies can occur, how can even a single-threaded program work correctly? A little chance exists, that an thread moves so often between two cores, that both caches contain copies of the process-local data. But this never should cause trouble, because single-threaded code was never required to use Interlocked access to its private data. 3.1) Chances are higher for a multi-threaded application, where the caches can contain any number of copies of shared (main thread) memory areas. But what would this mean to threaded code in general? I cannot believe that thread-aware code must use Interlocked access to *all* variables, even in the main thread, because no procedure can know from which thread it is actually called, in which core. That said I have some doubts, regarding your conclusions. Can you run your test again, assuring that only one thread can access the list at the same time, but *without* the Interlocked updates? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
Vinzent Höfler schrieb: On Tue, 28 Jun 2011 15:54:35 +0200, Michael Schnell mschn...@lumino.de wrote: But if you do the same with volatile static int x; the code will stay and another thread can watch x growing in a time sharing system. No, it can't. volatile just ensures that accessing the variable results in actual memory accesses. That does not mean cache-coherence, so another core may still see other (as in older) values. I dare to disagree. When reading a volatile variable requires a memory (RAM) read in one core, it will require the same read in any other core, and updates have to occur in write-through into the RAM. A difference could occur only, when the memory access may end up in the cache instead of in RAM. Question is, what makes one variable use read/write-through, while other variables can be read from the cache, with lazy-write? Is this a compiler requirement, which has to enforce read/write-through for all volatile variables? But if so, which variables (class fields...) can ever be treated as non-volatile, when they can be used from threads other than the main thread? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
Andrew Brunner schrieb: On Tue, Jun 28, 2011 at 9:33 AM, Michael Schnell mschn...@lumino.de wrote: And this has been discussed in the other message: If the variable in fact is global the compiler needs to avoid caching it, if it is static and the function is in another module it might still decide to cache it, but you are right: it is not likely that it does make this difference. Well, I think one issue is that each core has it's own cache. 1.) How can we get the core to not relent and have the code handed off to another core until we're finished? Never, in a preemptive multi-tasking environment. It's easier to *encourage* such swapping, by inserting Sleep calls. 2.) How can we get the core to have a synchronised copy of a particular variable (aside from CAS)? How can we get *unsynchronized* copies of the same variable, to prove the need for explicit synchronization? And how to prove that the copies *are* different, with means that do not happen to enforce synchronicity themselves? Please note that we'll have to restrict the sample code in a way, that leaves *no* room for *accidental* concurrent access, bypassing the one-thread-only access protection. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] volatile variables
On Tue, 28 Jun 2011 23:29:52 +0200, Hans-Peter Diettrich drdiettri...@aol.com wrote: Vinzent Höfler schrieb: No, it can't. volatile just ensures that accessing the variable results in actual memory accesses. That does not mean cache-coherence, so another core may still see other (as in older) values. I dare to disagree. When reading a volatile variable requires a memory (RAM) read in one core, it will require the same read in any other core, and updates have to occur in write-through into the RAM. Sorry, no. Memory access does not mean RAM here, it simply means that the compiler is not allowed to keep the value in a register or collapse multiple writes to the same location into a single one. (Ages ago, this happened to me on a memory-mapped i8254, where the counter register requires two 8-bit accesses to the same (memory-mapped) address and the compiler simply removed the first write). So, memory access /might/ be the local cache of the core, unless the actual memory region is write-through (because it's memory-mapped I/O, which was the original intent of volatile. See above.). A difference could occur only, when the memory access may end up in the cache instead of in RAM. But that's precisely what would happen. Question is, what makes one variable use read/write-through, while other variables can be read from the cache, with lazy-write? Synchronisation. Memory barriers. That's what they are for. Is this a compiler requirement, which has to enforce read/write-through for all volatile variables? No. volatile (at least in C) does not mean that. It was never intended for synchronisation between threads, cores, or even multiple processors. This is a misconception probably stemming from the fact that it was used to synchronise accesses to global variables within interrupt-handlers and the like where this is totally valid as long as there's only one single processor running all the code. The picture immediately changes if such an interrupt-handler (e.g. another thread) is executed on a different processor/core/whatchamacallit. But if so, which variables (class fields...) can ever be treated as non-volatile, when they can be used from threads other than the main thread? Without explicit synchronisation? Actually, none. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling FPC with DEBUG
On Tue, Jun 28, 2011 at 9:23 AM, Marcos Douglas m...@delfire.net wrote: Hi, I compile FPC with success using my tutorial: http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29 Questions: 1- How can I compile all packages with DEBUG option? 2- How can I compile just one package, eg fcl-xml, with DEBUG option? Thanks, Marcos Douglas 1) http://free-pascal-general.1045716.n5.nabble.com/Building-FPC-with-debug-information-td3211375.html 2) Did you try running make inside the dir with debug then running the normal compileinstall procedure? AFAICT fpc-pascal was ok (if not better) for this question. -Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling FPC with DEBUG
2011/6/28 Flávio Etrusco flavio.etru...@gmail.com On Tue, Jun 28, 2011 at 9:23 AM, Marcos Douglas m...@delfire.net wrote: Hi, I compile FPC with success using my tutorial: http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29 Questions: 1- How can I compile all packages with DEBUG option? 2- How can I compile just one package, eg fcl-xml, with DEBUG option? Thanks, Marcos Douglas Finally... =) 1) http://free-pascal-general.1045716.n5.nabble.com/Building-FPC-with-debug-information-td3211375.html Thanks, I will try. BTW, what that mean DEBUG=1? Is it exists =2, =3, etc? 2) Did you try running make inside the dir with debug then running the normal compileinstall procedure? No, I didn't because I didn't know this procedure. AFAICT fpc-pascal was ok (if not better) for this question. I posted in fpc-pascal, but nobody answered me! Marcos Douglas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiling FPC with DEBUG
Thanks, I will try. BTW, what that mean DEBUG=1? Is it exists =2, =3, etc? AFAIK no. 2) Did you try running make inside the dir with debug then running the normal compileinstall procedure? No, I didn't because I didn't know this procedure. AFAICT fpc-pascal was ok (if not better) for this question. I posted in fpc-pascal, but nobody answered me! I know, that's why I said that ;-) I was going to reply there yesterday but I couldn't because my internet connection (TIM 3G) was problematic. And still is :-/ Sometimes people take time to reply. Specially when the answer was not so difficult to find in google ;-) -Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
