NO

Recent Posts

Pages: 1 [2] 3 4 ... 10
11
General discussions / Re: How to Cross Compile 32-Bit
« Last post by John Z on October 11, 2020, 04:37:42 pm »
If you are still using PellesC version 9 then you select x86 or x64 on the Project Options Compiler page.  Using either version there can be quite a number of code changes that will need to be made, especially if this is a windows program you are changing.  Just changing the setting from 64 to 32 or 32 to 64 won't automagically fix everything that needs to be changed.

John Z
12
Bug reports / Re: Unexpected debugging behavior
« Last post by John Z on October 11, 2020, 04:30:54 pm »
I ran the test code on a Windows 7 machine with PellesC version 9.  Here is what I found so far.
If I debug the program without ever selecting any debug information I get a notice that there is no debug information then after acknowledging that I get an assembly code display.  The same thing happens regardless of setting a breakpoint or not.

Next I selected debug data on all Project Option pages which have the option to include debug data.
Then debugging the program it shows the same outputs that are being discussed:  Debug with no breakpoint stops at line 4(main entry), then pressing F5 continues and shows assembly listing. Debug with a breakpoint on line 7 skips the stop at line 4 and proceeds immediately to the assembly listing.

This all seems to make some sense to me.  If I'm debugging without breakpoints wouldn't I want the debug to initiate at the start procedure so that I could step thru?  I added a small procedure in front of main then have main call it after puts().  Debug without breakpoint still starts a main.

Caveat is I rarely use debug ( I could not even find "Always break on entry-point" setting) so maybe the only thing of value here is that the debug behavior is the same on windows 7 with PellesC version 9 as it is on windows 10 with PellesC version 10.

John Z
13
Bug reports / Re: Unexpected debugging behavior
« Last post by Pelle on October 10, 2020, 07:41:14 pm »
Thank you for the example. I get the same effect on my machine (Windows 10, version 2004) for this program, but not for other (similar) programs(!).

The debugger apparently receives a request for a breakpoint in cmd.exe, which is where it stops (no source code, so assembly code). If I use "Debug"->"Go", or press F5, the debugger continues to the example program and stops at the breakpoint on puts(), as I expect.

At the moment I don't know if this is a new Microsoft "feature", or what is going on, to be honest...
I will continue to investigate, but unclear when I have an answer...
14
Bug reports / Re: Unexpected debugging behavior
« Last post by Werner on October 08, 2020, 08:19:01 pm »
Thanks for your response.

The reported issue can be reproduced by the following small program.

 - Starting the debugger with no breakpoint set, works fine.

- Starting the debugger with a breakpoint set on the output line (line 7), results in an assembly listing.

Code: [Select]
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
system("dir");
puts("After system().");
return 0;
}

Is this an expected behavior?

Werner
15
General discussions / Re: How to Cross Compile 32-Bit
« Last post by Robert on October 08, 2020, 04:12:14 pm »
What exactly you need?
Cross-compile is a process to produce on a machine executables that will run on other machines having OS and/or processors different from the the compiling one.
PellesC actually supports only one processor family (IA-32 and IA-64), and only one OS: MS-WIN.
Because each 64 bits machine can run 32bits executables we cannot strictly speak of cross-compilation when the code is produced for a 32bits processor on a 64bits machine.
In the past, when PellesC come with ARM processors support, there was some kind of cross-compilation, but only for MS-WIN OS.

Hi Frankie:

I'm not sure what Daniel needs but I was wondering how to change an existing 64 bit project to a 32 bit project in the IDE.

How can a project be compiled for 64 bit and then, with a click of "The Magic Button" in the IDE, compile for 32 bit?

Never mind. I found it. Right click on the Project name in the project window, click on Properties, click on Project tab and set the Type in the drop down box.
16
General discussions / Re: How to Cross Compile 32-Bit
« Last post by Robert on October 08, 2020, 04:02:41 pm »
What exactly you need?
Cross-compile is a process to produce on a machine executables that will run on other machines having OS and/or processors different from the the compiling one.
PellesC actually supports only one processor family (IA-32 and IA-64), and only one OS: MS-WIN.
Because each 64 bits machine can run 32bits executables we cannot strictly speak of cross-compilation when the code is produced for a 32bits processor on a 64bits machine.
In the past, when PellesC come with ARM processors support, there was some kind of cross-compilation, but only for MS-WIN OS.

Hi Frankie:

I'm not sure what Daniel needs but I was wondering how to change an existing 64 bit project to a 32 bit project in the IDE.

How can a project be compiled for 64 bit and then, with a click of "The Magic Button" in the IDE, compile for 32 bit?



17
General discussions / Re: How to Cross Compile 32-Bit
« Last post by frankie on October 08, 2020, 10:01:01 am »
What exactly you need?
Cross-compile is a process to produce on a machine executables that will run on other machines having OS and/or processors different from the the compiling one.
PellesC actually supports only one processor family (IA-32 and IA-64), and only one OS: MS-WIN.
Because each 64 bits machine can run 32bits executables we cannot strictly speak of cross-compilation when the code is produced for a 32bits processor on a 64bits machine.
In the past, when PellesC come with ARM processors support, there was some kind of cross-compilation, but only for MS-WIN OS.
18
General discussions / How to Cross Compile 32-Bit
« Last post by daniel_bingamon on October 07, 2020, 08:04:32 pm »
I want an application to be cross compiled as 32-bit so that it will run on 32-bit machines.
What to I need to do in "Project Options" to set this?
19
Bug reports / Re: Speed Optimization: buggy or am I terribly missing something?
« Last post by TimoVJL on October 06, 2020, 08:41:45 pm »
Optimizations are difficult.
I have a some  code, where also msvc fails, so none is perfect.
I can't publish my code, as it is private for a one company.
20
Bug reports / Re: Unexpected debugging behavior
« Last post by Pelle on October 06, 2020, 07:15:26 pm »
"Always break on entry-point" breaks at the entry-point of the module (startup code), which usually leads to main()/WinMain()/DllMain(), but could possibly lead to something else (for a custom build).

I can't immediately reproduce your other problem.

Not sure it helps, but a completely different approach is to use the breakpoint "statement":
Code: [Select]
__debugbreak();which will always break in debug builds, but is a no-op in release builds.
Pages: 1 [2] 3 4 ... 10