Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: Thoth on September 25, 2024, 02:51:05 pm

Title: Breakpoints Not Breaking on Flow Control or Assignment Statements
Post by: Thoth on September 25, 2024, 02:51:05 pm
Hello People,

I am using Code::Blocks version:
Name                   : Code::Blocks
Version                : svn-r13046
SDK Version            : 2.23.0

When I set a breakpoint on an if statement, the code stops on a statement within the block, not on the if statement as I expect. Also, when I set a breakpoint on an assignment statement the code stops on the next non-assignment statement. It looks like the debugger will not stop on any flow control statement, but I have not fully checked this.
Did something change in the last several versions?

I prefer to have programs break on flow control statements so I can evaluate what is going to happen. More importantly, I expect the program to halt wherever I have a breakpoint, regardless of the instruction.

I have enabled debugging symbols and tried variations of optimizations. I have also set both target options as well as project options.
-Og; Optimize debugging executable (compile speed, execution speed and better debugging)
-g; Produce debugging symbols
-O1; Linker output optimization (level 1)

Always breaks on statement below with '--->'.
Never stops on if statement, the line in the if block.
Never stops on the DevicesCount assignment statement.
Code
	if (oDevices.find(0) != oDevices.end()) {
CmdRez = oDevices.at(0);
}

if (oDevices.size() > 1)
{
std::map<uint8_t, std::map<uint16_t, std::vector<uint8_t>>>::const_iterator ItorDevices;
std::map<uint16_t, std::vector<uint8_t>> oADevice;
std::map<uint16_t, std::vector<uint8_t>> TempMap;
std::vector<uint8_t> DevicesVector;
uint8_t DeviceCount = 0;

// ADC_LibUSBDevices
---> ResultVector.push_back(((ADC_LibUSBDevices >> 8) & 0xFF));

While researching another issue I thought I saw a post about current versions of Code::Blocks no longer stopping on flow control. However, I was not able to locate whatever it was I saw.

What else can I try? I want to have the program break on flow control and assignment statements.


=thoth=
Title: Re: Breakpoints Not Breaking on Flow Control or Assignment Statements
Post by: ollydbg on September 25, 2024, 04:43:44 pm
Quote
I have enabled debugging symbols and tried variations of optimizations.

My suggestion: if you want to debug the code, it is recommended that you do not have optimization option in your compiler option, I mean -O0 option is needed.
Title: Re: Breakpoints Not Breaking on Flow Control or Assignment Statements
Post by: Thoth on September 25, 2024, 07:25:36 pm
Hello ollydbg,

I have tried -O0.

The program still does not break on if statements (or other flow control statements) and still skips assignment statements.




=thoth=
Title: Re: Breakpoints Not Breaking on Flow Control or Assignment Statements
Post by: ollydbg on September 26, 2024, 01:49:00 am
Hello ollydbg,

I have tried -O0.

The program still does not break on if statements (or other flow control statements) and still skips assignment statements.




=thoth=

I think you may need to create a minimal program, and share it here. So others can test and reproduce it.

But from my point of view, this is mainly a compiler or debugger issue.
Title: Re: Breakpoints Not Breaking on Flow Control or Assignment Statements
Post by: stahta01 on September 26, 2024, 02:17:50 am
Hello ollydbg,

I have tried -O0.

The program still does not break on if statements (or other flow control statements) and still skips assignment statements.




=thoth=

I think you may need to create a minimal program, and share it here. So others can test and reproduce it.

But from my point of view, this is mainly a compiler or debugger issue.

Posting a full bull log might show the problem.

Tim S.
Title: Re: Breakpoints Not Breaking on Flow Control or Assignment Statements
Post by: Thoth on October 01, 2024, 06:37:33 am
Hello Tim,

Thank you for answering.

The build log is very long.

I have filtered the log to a single component. A pastebin of the distilled items is at: https://pastebin.com/FcMWZRJE


The compilation options are:
Code
COLLECT_GCC_OPTIONS='-Wall' '-std=c++11' '-fPIC' '-fexceptions' '-v'
'-m64' '-Og' '-g' '-I' '/Libs' '-I' '/Libs/Debian_x64_Debug_Static_GNU/'
'-I' '/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Libs' '-I'
'/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks//../../LPOThirdParty/Source' '-I' '/Libraries/FTDI1/' '-I' '/Libraries/SQLite3/' '-I' '/Libraries/USB1/' '-I' '/usr/include/' '-c' '-o' '/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Out/Debian_x64_Debug_Static_GNU/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Out/Debian_x64_Debug_Static_GNU/CodeTemp/ins_LPOCode/LPO/Source/'

The linker options are:
Code
as -v -I /Libs -I /Libs/Debian_x64_Debug_Static_GNU/ -I
/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Libs -I
/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks//../../LPOThirdParty/Source
-I /Libraries/FTDI1/ -I /Libraries/SQLite3/ -I /Libraries/USB1/ -I
/usr/include/ --gdwarf-5 --64 -o
/SG3Data/CodeTemp/ins_LPOCode/LPO/CodeBlocks/../Out/Debian_x64_Debug_Static_GNU/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.o /tmp/ccd1ayCl.s
GNU assembler version 2.40 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Debian) 2.40
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/12/../../../:/lib/:/usr/lib/

As a reminder, I set break points at lines with 'BP' and the debugger halts at '--->'
Code

BP ResultVector[2] = ((DevicesVector.size() >> 8) & 0xFF);
ResultVector[3] = (DevicesVector.size() & 0xFF);

/// Add the Devices Vector to the Command Result Vector.
ResultVector.insert(ResultVector.end(), DevicesVector.begin(), DevicesVector.end());
---> DevicesVector.clear(); std::vector<uint8_t>().swap(DevicesVector);




=thoth=
Title: Re: Breakpoints Not Breaking on Flow Control or Assignment Statements
Post by: ollydbg on October 01, 2024, 07:29:51 am
Can you show use the "debugger plugin's debug log" when you start debugging?

It is in the "Debugger" panel, you also need to enable the "debugger plugin's debug log" in the Debugger plugin's setting dialog->"Full (Debug) log" option.

Is that also happens when you debug the code without C::B? I mean in the command line shell(bash)?
Title: Re: Breakpoints Not Breaking on Flow Control or Assignment Statements
Post by: Thoth on October 01, 2024, 08:56:16 pm
Hello ollydbg,

In dealing with the debugger, I learned something new.
Thanks!

I put the full debug log at https://pastebin.com/7S6jSzZR with superfluous information removed.

I have attached an image of this post showing a breakpoint at line 577 and the debugger stopping at line 583.

A relavant line from the debugger line is:
Code
[debug]> break "/SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:577"
[debug]Breakpoint 2 at 0xd9a4: file /SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp, line 583.
I do not know why Breakpoint 2 is created at line 583.

The breakpoint is skipped when I perform the process manually
Code
/usr/bin/gdb -nx -fullname -quiet  -args /SG3Data/CodeTemp/ins_LPOCode/LPO/Bin/Debian_x64_Debug_Static_GNU/lpo_d
Reading symbols from /SG3Data/CodeTemp/ins_LPOCode/LPO/Bin/Debian_x64_Debug_Static_GNU/lpo_d...
(gdb) set confirm off
(gdb) set args scan blerg probe -JDN 2459034.79167 -Lat 37.3688 Long=-122.0363 -Unk0 Val0 -Fucked= -f= Switch1 Switch2    Switch3  -dead=beef -Switch4 -Switch5
(gdb) break "/SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:577"
Breakpoint 1 at 0xd9a4: file /SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp, line 583.
(gdb) run
Starting program: /SG3Data/CodeTemp/ins_LPOCode/LPO/Bin/Debian_x64_Debug_Static_GNU/lpo_d scan blerg probe -JDN 2459034.79167 -Lat 37.3688 Long=-122.0363 -Unk0 Val0 -Fucked= -f= Switch1 Switch2    Switch3  -dead=beef -Switch4 -Switch5
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

... program output ...

[Thread 0x7ffff7a1e6c0 (LWP 158065) exited]

Thread 1 "lpo_d" hit Breakpoint 1, LPOProgram::DoCommandScan ( ... )
    at /SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:583
��/SG3Data/CodeTemp/ins_LPOCode/LPO/Source/lpo_program.cpp:583:14685:beg:0x5555555619a4
(gdb) q

I expected the debugger to break at line 577.

I am able to replicate the behavior throughout the program being debugged.
I see the behavior with assignment and flow control statements.


=thoth=
Title: Re: Breakpoints Not Breaking on Flow Control or Assignment Statements
Post by: Miguel Gimenez on October 02, 2024, 12:46:30 pm
My opinion is that lines 577 to 582 have been optimized out, but the log data in pastebin is not available:
Quote
Error, this is a private paste or is pending moderation

You can add it here as a zip file.