file 'FileName' has no debug symbols lazarus / 12-Debugger ---------------------------------------------------------------------- Xor-el · 2019-07-12 22:38 Hello all, Has anyone been able to debug a program successfully using Lazarus and GDB on OSes other than Windows, Linux or Mac? I seem to be getting the above error file 'xxxx' has no debug symbols when I try to debug a simple program in my OpenBSD Lazarus installation, (Yes my project is in debug mode). I can debug this same program with the same setup on Windows and Linux. Any hints all? ---------------------------------------------------------------------- Martin_fr · 2019-07-12 23:40 I havent tried it. So just a blind guess from me. Have you tried "Stabs" vs "Dwarf"? Also "external debug info" on/off? ---------------------------------------------------------------------- Xor-el · 2019-07-13 05:39 Quote from: Martin_fr on July 13, 2019, 01:40:10 amI havent tried it. So just a blind guess from me. Have you tried "Stabs" vs "Dwarf"? Also "external debug info" on/off? Yes, I have tried these options. ---------------------------------------------------------------------- 440bx · 2019-07-13 06:33 Quote from: Xor-el on July 13, 2019, 12:38:29 amHello all, Has anyone been able to debug a program successfully using Lazarus and GDB on OSes other than Windows, Linux or Mac? I seem to be getting the above error file 'xxxx' has no debug symbols when I try to debug a simple program in my OpenBSD Lazarus installation, (Yes my project is in debug mode). I can debug this same program with the same setup on Windows and Linux. Any hints all? Another blind guess/idea... have you tried running objdump on the resulting executable ? ... objdump should tell you if the executable contains debug info or not... the presence or absence of debug symbols would be a good thing to ascertain. ---------------------------------------------------------------------- Thaddy · 2019-07-13 07:23 Well, marcov seems to know more about the bsd flavors. Ask him. It is probably stabs vs dwarf but which versions to use? I have no clue. I have a couple of vmś running bsd's but I hardly need them. Aside: when debugging seems an issue, I use instrumentation, like - mostly - inserting asserts (and using the default() intrinsic). That comes a long way very often. BSD's are a lot stricter than most nixes. Also note: e.g. openbsd has a couple of features that may interfere with the usual debugging, See https://man.openbsd.org/malloc_conceal.3  This may or may not be related. ---------------------------------------------------------------------- Xor-el · 2019-07-13 08:29 Quote from: 440bx on July 13, 2019, 08:33:18 amAnother blind guess/idea... have you tried running objdump on the resulting executable ? ... objdump should tell you if the executable contains debug info or not... the presence or absence of debug symbols would be a good thing to ascertain. Output from objdump (had to use the external debug info off switch when compiling the binary in Lazarus). also, the funny thing is that the binary runs fine so am shocked why it says Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i objdump: CryptoLib: Invalid bfd target Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Xor-el# objdump -debugging CryptoLib       objdump: CryptoLib: Invalid bfd target Xor-el# objdump --debugging CryptoLib   CryptoLib:     file format elf64-x86-64   objdump: CryptoLib: no recognized debugging information Xor-el# objdump --header CryptoLib | grep debug  27 .debug_aranges 000820d0  0000000000000000  0000000000000000  01494ce0  2**0 28 .debug_info   03192f54  0000000000000000  0000000000000000  01516db0  2**0 29 .debug_abbrev 0005e4a4  0000000000000000  0000000000000000  046a9d04  2**0 30 .debug_line   002789dd  0000000000000000  0000000000000000  047081a8  2**0 31 .debug_frame  001d5cc8  0000000000000000  0000000000000000  04980b88  2**3 Xor-el# ---------------------------------------------------------------------- Xor-el · 2019-07-13 08:31 Quote from: Thaddy on July 13, 2019, 09:23:58 amWell, marcov seems to know more about the bsd flavors. Ask him. It is probably stabs vs dwarf but which versions to use? I have no clue. Thanks Thaddy, will ask him, meanwhile I have tried the whole debug info configurations yet unfortunately no progress. ---------------------------------------------------------------------- marcov · 2019-07-13 10:49 Is OpenBSD LLVM nowadays? If so try switching to GNU LD. I haven't done much BSD in the last two years, though I'm planning to start again (to fix freebsd for llvm) Are you working with trunk/3.2?  Nikolai and Pierre did a lot of work on it for openbsd ---------------------------------------------------------------------- Xor-el · 2019-07-13 10:55 Quote from: marcov on July 13, 2019, 12:49:02 pmIs OpenBSD LLVM nowadays? If so try switching to GNU LD. Thanks for replying. Any hints on how to do this please? Forgive me but am a BSD newbie. Also yes, I am working with 3.2.0 Fixes. Quote haven't done much BSD in the last two years, though I'm planning to start again (to fix freebsd for llvm) go marcov, go marcov ---------------------------------------------------------------------- 440bx · 2019-07-13 15:01 Quote from: Xor-el on July 13, 2019, 10:29:47 amOutput from objdump (had to use the external debug info off switch when compiling the binary in Lazarus). also, the funny thing is that the binary runs fine so am shocked why it says Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i objdump: CryptoLib: Invalid bfd targetthe bfd is the in memory debug symbol table objdump creates.  The fact that it cannot create it is most likely the result of an incorrect (or downright missing) reference to the symbol tables contained in the exe. The reason the binary runs fine is because the debugging info is not needed to run the executable.  The debug info could be a complete mess and the OS would not be bothered to care but, a debugger that wants to use that information would definitely care a great deal. The next thing you should do is, compile/build directly with the compiler from a command line, IOW, no Lazarus involved and re-run objdump on the exe produced directly by the compiler. if objdump is "happy" with the exe then gdb will likely be happy too and, it would indicate that some setting in Lazarus is causing the debug info to be emitted incorrectly (or not emitted at all.) if compiling directly yields the same result as what you posted then, the most likely reason is, the compiler is outputting invalid references to the debug symbol tables contained in the exe. ---------------------------------------------------------------------- marcov · 2019-07-13 17:33 Quote from: Xor-el on July 13, 2019, 12:55:33 pmQuote from: marcov on July 13, 2019, 12:49:02 pmIs OpenBSD LLVM nowadays? If so try switching to GNU LD. Thanks for replying. Any hints on how to do this please? Forgive me but am a BSD newbie. Check if "/usr/bin/ld" is a symlink and if so change it to gnu ld (usually gld, or more often, ld.bfd) Also yes, I am working with 3.2.0 Fixes. Quote haven't done much BSD in the last two years, though I'm planning to start again (to fix freebsd for llvm) go marcov, go marcov  [/quote] ---------------------------------------------------------------------- Xor-el · 2019-07-13 18:41 Quote from: marcov on July 13, 2019, 07:33:43 pm Check if "/usr/bin/ld" is a symlink and if so change it to gnu ld (usually gld, or more often, ld.bfd)  haven't done much BSD in the last two years, though I'm planning to start again (to fix freebsd for llvm) I just checked those files now and no they are not symlinks, they are real files. the files are ld and  ld.bfd any other ideas please? ---------------------------------------------------------------------- trev · 2019-07-13 22:22 QuoteOpenBSD - Oct 23, 2018; 6:42am HEADS UP: amd64 has switched to lld The amd64 architecture has now switched to LLVM's lld linker as the default ld(1). I read that announcement from the OpenBSD ports mailing list as meaning that ld was switched to lld. You could try mv'ing ld to ld.lld and symlinking ld.bfd to ld.