Recent Posts

31

Help / Compiler Optimizations

« Last post by mikejp56 on April 19, 2024, 06:34:52 pm »

Hi All,
I am using CB with Linux Mint 20. I get the following warning "/usr/lib/avr/include/util/delay.h:112:3: warning: #warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed" [-Wcpp]
 # warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed"
I have set the compiler optimizations for 1, 2, and 3, but I still get the same warning.
I am pretty new to CodeBlocks and AVR programming.
Please point me in the correct direction.
Thanks for reading.
Regards,
mikejp56

32

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by Miguel Gimenez on April 19, 2024, 01:55:30 pm »

GNU has changed the output of the "info breakpoints" command in GDB 13. From Sourceware change log:

* "info breakpoints" now displays enabled breakpoint locations of
  disabled breakpoints as in the "y-" state.  For example:

   (gdb) info breakpoints
   Num     Type           Disp Enb Address            What
   1       breakpoint     keep n   <MULTIPLE>
   1.1                         y-  0x00000000000011b6 in ...
   1.2                         y-  0x00000000000011c2 in ...
   1.3                         n   0x00000000000011ce in ...

The Enb column previously showed 'y' or 'n', now it shows 'y-' or 'n'. This may be fooling the debugger plugin.

33

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by Grit Clef on April 19, 2024, 12:51:43 pm »

Then maybe Xaviou's build can be suitable?

34

Plugins development / Re: Code completion using LSP and clangd

« Last post by MaxGaspa on April 19, 2024, 11:24:34 am »

I see that you're not clicking either inside a class or a function.
Do this, after the clicked file has parsed, click inside a function, not at the top of an editor file.

Yes, clicking inside a function or class works. Thanks

35

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by nenin on April 19, 2024, 07:43:50 am »

Never mind I ve figured it out turns out these nightly versions do not support 13.2 yet. So I have switched to 13.1 and now it works.

I have nighties (including last one) running with 13.2 gcc (nixman) without such problems. 

36

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by nenin on April 19, 2024, 07:41:48 am »

Recent GDB introduced some changes in the output so parsing failed. This was fixed in r13162 a year ago, try the last nightly.

Here is potential other issue: The 01 April 2024 build (13496) is actually built with gcc 13.2, all its dlls- with gcc 13.1. At my experience  mixing of the c++ libraries is a lottery.

37

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by mckl on April 19, 2024, 07:16:26 am »

Never mind I ve figured it out turns out these nightly versions do not support 13.2 yet. So I have switched to 13.1 and now it works.

38

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by mckl on April 19, 2024, 02:08:51 am »

Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\Users\mstar\Desktop\CPP_AIO4\BookIV\Chapter02\BuggyProgram\
Adding source dir: C:\Users\mstar\Desktop\CPP_AIO4\BookIV\Chapter02\BuggyProgram\
Adding file: C:\Users\mstar\Desktop\CPP_AIO4\BookIV\Chapter02\BuggyProgram\bin\Debug\BuggyProgram.exe
Changing directory to: C:/Users/mstar/Desktop/CPP_AIO4/BookIV/Chapter02/BuggyProgram/.
Set variable: PATH=.;C:\mingw64\bin;C:\mingw64;C:\Program Files (x86)\Common Files\Oracle\Java\java8path;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR;C:\Program Files\Intel\WiFi\bin;C:\Program Files\Common Files\Intel\WirelessCommon;C:\Program Files\Git\cmd;C:\Program Files\dotnet;C:\Users\mstar\AppData\Local\Programs\Python\Python38\Scripts;C:\Users\mstar\AppData\Local\Programs\Python\Python38;C:\Users\mstar\AppData\Local\Microsoft\WindowsApps;\;C:\Program Files\JetBrains\PyCharm Community Edition 2020.3\bin

[debug]Command-line: C:\mingw64\bin\gdb.exe -nx -fullname -quiet  -args C:/Users/mstar/Desktop/CPP_AIO4/BookIV/Chapter02/BuggyProgram/bin/Debug/BuggyProgram.exe
[debug]Working dir : C:\Users\mstar\Desktop\CPP_AIO4\BookIV\Chapter02\BuggyProgram

Starting debugger: C:\mingw64\bin\gdb.exe -nx -fullname -quiet  -args C:/Users/mstar/Desktop/CPP_AIO4/BookIV/Chapter02/BuggyProgram/bin/Debug/BuggyProgram.exe
done

[debug]terminate called after throwing an instance of 'std::system_error'
[debug]terminate called recursively
[debug]  what():  Invalid argument
[debug]> set prompt >>>>>>cb_gdb:

Setting breakpoints
Debugger finished with status 1

39

Using Code::Blocks / Re: gdb of better compiler not working

« Last post by mckl on April 19, 2024, 12:05:49 am »

Yeah it is already in full

40

Plugins development / Re: Code completion using LSP and clangd

« Last post by Pecan on April 18, 2024, 11:16:15 pm »

hey @Pecan
sorry to bother you again but I have encounter an unusual behavior.
I was trying to use a large single file libraryhttps://github.com/mackron/miniaudio.
It has a single headerfile: miniaudio.h <--- 62k lines

when I try to open the header file or search for declaration through the main.c, whole code blocks freezes for solid 1-2 mins, weanwhile the mouse gradually becomes unresponsive until it's completely frozen and the screen turns black. Throws an error that Clangd_Cliet has stopped at the end.

I not sure if it's because my laptop isn't powerful enough. because the plugin usually worked smooth with other large libraries.

Apart from this single instance the plugin works fine and it has been very helpful.

I'll have a look at it.
Please attach your .cbp file for the project and your main.c  to a forum reply, so I can mirror what's happening.
Thanks for the report.

After testing and tracing clangd_client and the miniAudio source I believe it will not be possible to pass that 4meg miniAudio.h file to clangd.

I have a relatively fast system, but clangd never finished parsing the header file before it crashed attempting to create a response file which would have been many times the size of the source file (about 24meg or more) after it formatted a response containing line/col/symbol/diagnostics/fix suggestions, etc.
If it didn't give out of memory, it sure would have caused Clangd_client to.

That header file will have to be broken up into multiple headers in order for clangd to handle it.

Note from opinionated self: I really do not consider creating a 4meg header file as acceptable software design. It's just going to create grief for anyone using it. If not now, certainly in the future.