Building Thunderbird / Firefox with LLVM 3.4 or newer on i386 results in a crash during the install phase; this problem does not happen with amd64. The issue has shown up both with a VM running under VMware and on bare metal but I have also been able to run on other bare metal i386 systems without issue. My guess is this could be a code generation issue with LLVM and from what I have heard mentioned elsewhere this started somewhere between LLVM 3.3 and 3.4 but I don't know if this is really an LLVM issue or an issue with the relevant code within the installer for Thunderbird / Firefox.
gmake[1]: Entering directory '/usr/ports/pobj/thunderbird-24.2.0/build-i386/mail/installer'
OMNIJAR_NAME=omni.ja \
/usr/ports/pobj/thunderbird-24.2.0/build-i386/mozilla/_virtualenv/bin/python /usr/ports/pobj/thunderbird-24.2.0/comm-esr24/mozilla/toolkit/mozapps/installer/packager.py -DMOZ_GLUE_IN_PROGRAM -DMOZ_THUNDERBIRD=1 -DOSTYPE=\"OpenBSD5\" -DOSARCH=OpenBSD -DNO_NSPR_10_SUPPORT -DAB_CD=en-US -DMOZ_APP_NAME=thunderbird -DPREF_DIR=defaults/pref -DMOZ_ENABLE_GNOME_COMPONENT=1 -DMOZ_GTK2=1 -DJAREXT= -DMOZ_NATIVE_NSPR=1 -DMOZ_NATIVE_NSS=1 -DMOZ_CHILD_PROCESS_NAME=plugin-container -DDLL_PREFIX=lib -DDLL_SUFFIX=.so.28.0 -DBIN_SUFFIX= -DBINPATH=bin \
--format omni \
--removals /usr/ports/pobj/thunderbird-24.2.0/comm-esr24/mail/installer/removed-files.in \
\
\
\
--optimizejars \
\
package-manifest ../../mozilla/dist ../../mozilla/dist/thunderbird \
--non-resource defaults/messenger/mailViews.dat
Executing /usr/ports/pobj/thunderbird-24.2.0/build-i386/mozilla/dist/bin/xpcshell -g /usr/ports/pobj/thunderbird-24.2.0/build-i386/mozilla/dist/bin/ -a /usr/ports/pobj/thunderbird-24.2.0/build-i386/mozilla/dist/bin/ -f /usr/ports/pobj/thunderbird-24.2.0/comm-esr24/mozilla/toolkit/mozapps/installer/precompile_cache.js -e precompile_startupcache("resource://gre/");
Traceback (most recent call last):
File "/usr/ports/pobj/thunderbird-24.2.0/comm-esr24/mozilla/toolkit/mozapps/installer/packager.py", line 375, in <module>
main()
File "/usr/ports/pobj/thunderbird-24.2.0/comm-esr24/mozilla/toolkit/mozapps/installer/packager.py", line 367, in main
args.source, gre_path, base)
File "/usr/ports/pobj/thunderbird-24.2.0/comm-esr24/mozilla/toolkit/mozapps/installer/packager.py", line 148, in precompile_cache
errors.fatal('Error while running startup cache precompilation')
File "/usr/ports/pobj/thunderbird-24.2.0/comm-esr24/mozilla/python/mozbuild/mozpack/errors.py", line 101, in fatal
self._handle(self.FATAL, msg)
File "/usr/ports/pobj/thunderbird-24.2.0/comm-esr24/mozilla/python/mozbuild/mozpack/errors.py", line 96, in _handle
raise ErrorMessage(msg)
mozpack.errors.ErrorMessage: Error: Error while running startup cache precompilation
I am looking for some assistance with the relevant tools to try and determine the source of this Illegal instruction error.
Core was generated by `xpcshell'.
Program terminated with signal 4, Illegal instruction.
I used the core file instead of running gdb as you specified..
# egdb build-i386/mozilla/dist/bin/xpcshell build-i386/mail/installer/xpcshell.core
Python Exception <type 'exceptions.ImportError'> No module named gdb:
warning:
Could not load the Python gdb module from `/usr/local/share/gdb/python'.
Limited Python support is available from the _gdb module.
Suggest passing --data-directory=/path/to/gdb/data-directory.
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd5.5".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/ports/pobj/thunderbird-24.2.0/build-i386/mozilla/dist/bin/xpcshell...(no debugging symbols found)...done.
[New process 13685]
Core was generated by `xpcshell'.
Program terminated with signal 4, Illegal instruction.
#0 0x002ead4d in mozilla::BinaryPath::GetFile(char const*, nsIFile**) () from /usr/ports/pobj/thunderbird-24.2.0/build-i386/mozilla/dist/bin/libxul.so.28.0
(gdb) x/i $pc
=> 0x2ead4d <_ZN7mozilla10BinaryPath7GetFileEPKcPP7nsIFile+157>: ud2
(gdb) quit
# echo _ZN7mozilla10BinaryPath7GetFileEPKcPP7nsIFile+157 | c++filt
mozilla::BinaryPath::GetFile(char const*, nsIFile**)+157
looking for some assistance with the relevant tools to try and determine the source of this Illegal instruction error
Your first task is to understand what illegal instruction you are trying to execute.
Run xpcshell under GDB like so:
gdb --args /usr/ports/pobj/thunderbird-24.2.0/build-i386/mozilla/dist/bin/xpcshell \
-g /usr/ports/pobj/thunderbird-24.2.0/build-i386/mozilla/dist/bin/ -a \
/usr/ports/pobj/thunderbird-24.2.0/build-i386/mozilla/dist/bin/ -f \
/usr/ports/pobj/thunderbird-24.2.0/comm-esr24/mozilla/toolkit/mozapps/installer/precompile_cache.js -e \
precompile_startupcache("resource://gre/");
(gdb) run
... GDB will stop on SIGILL
(gdb) x/i $pc
Once you know what the illegal instruction is, you'll need to figure out why Clang produced it.
One likely possibility is the ud2 instruction, which Clang emits when it detects undefined behavior in the program.
Related
I am trying to debug AVX-512 instructions on an emulated CPU using Intel® Software Development Emulator but it doesn't work as desired after setting a breakpoint. I followed this blog post: Debugging Emulated Code on Linux*
In window #1:
~$ g++ -g -O0 -mavx512f main.cpp -o main # compile main.cpp file
~$ sde -debug -- ./main # enable debugging
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :54105
In window #2
# run debugger
~$ gdb ./main
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
# set target "target remote :portnumber"
(gdb) target remote :54105
Remote debugging using :54105
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fa7bbbcc100 in ?? () from /lib64/ld-linux-x86-64.so.2
# suspend program at main function
(gdb) break main
Breakpoint 1 at 0x2c9c: file /home/borrow/source/repos/se-test/main.cpp, line 165.
# start program execution from the beginning of the program
(gdb) run
The "remote" target does not support "run". Try "help target" or
"continue".
# step to next line of code
(gdb) step
Cannot find bounds of current function
# continue executing until next break point
(gdb) c
Continuing.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
[Inferior 1 (Remote target) exited normally]
In window #2: as you can see
gdb run should run a program but it doesn't work. gdb c should also run until the next breakpoint but executes the program and terminates. This command gives me the following warning message:
warning: Probes-based dynamic linker interface failed.
In window #1: The program runs and ends (without stopping).
Program code looks like this:
// main.cpp
#include <immintrin.h>
const int N=64;
int64_t srcA[N] = {0};
int64_t srcB[N] = {0};
int64_t dst[N] = {0};
void foo()
{
__m512i result,B,C;
for ( int i=0; i<N; i+=8 ){
B = _mm512_loadu_si512(&srcA[i]);
C = _mm512_loadu_si512(&srcB[i]);
result = _mm512_add_epi64(B,C);
_mm512_storeu_si512(&dst[i], result);
}
}
int main() {
...
foo();
...
}
I tried running AVX2 code without SDE emulator using gdb and it worked. First I start it on an emulated CPU with SDE, it fails. How can I solve this problem?
It seems to be broken for PIE executables
(confirmed on Arch GNU/Linux with GCC 10.2, GDB 10.1, SDE 8.33.)
Build with g++ -O2 -fno-pie -no-pie -g -march=skylake-avx512 and everything works. (I had to run gdb ./a.out instead of bare GDB; without that it couldn't find the right file even after connecting to the remote.)
$ g++ -O2 -march=skylake-avx512 -no-pie -fno-pie -g avx512.cpp
$ /opt/sde-external-8.33.0-2019-02-07-lin/sde64 -debug -- ./a.out
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :59783
Then in another terminal tab
$ gdb ./a.out
...
(gdb) target remote :59783
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f4f7033b090 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x401050: file avx512.cpp, line 29.
(gdb) b foo
Breakpoint 2 at 0x401190: file avx512.cpp, line 14.
(gdb) c
Continuing.
Breakpoint 1, main () at avx512.cpp:23
(gdb) layout asm
(copy-paste of some of the disassembly window)
│B+ 0x401120 <_Z3foov> xor eax,eax
│ 0x401122 <_Z3foov+2> nop WORD PTR [rax+rax*1+0x0]
│ >0x401128 <_Z3foov+8> vmovdqu64 zmm1,ZMMWORD PTR [rax+0x404260]
│ 0x401132 <_Z3foov+18> add rax,0x40
│ 0x401136 <_Z3foov+22> vpaddq zmm0,zmm1,ZMMWORD PTR [rax+0x404420]
│ 0x401140 <_Z3foov+32> vmovdqu64 ZMMWORD PTR [rax+0x404020],zmm0
│ 0x40114a <_Z3foov+42> cmp rax,0x200
│ 0x401150 <_Z3foov+48> jne 0x401128 <_Z3foov+8>
│ 0x401152 <_Z3foov+50> vzeroupper
│ 0x401155 <_Z3foov+53> ret
(gdb) layout src
asm-level and source-level debugging both work fine, stepping into intrinsic "functions" in avx512fintrin.h and so on when using stepi (aka si).
Without specifying the filename separately from connecting to the remote:
$ gdb
(gdb) target remote :46879
Remote debugging using :46879 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command.
0x00007f0f85830090 in ?? ()
(gdb)
(IDK if it matters that my .gdbinit includes layout reg, the full-screen terminal TUI mode. Nice when it works but somewhat buggy.)
Or as a super hacky workaround with PIE executables, I was also able to put a delay loop at the top of main, giving you a chance to attach and then control-C before SDE finishes executing your program.
Then I could set breakpoints and start single-stepping. (Presumably a sleep or read system call would work). Source-level debugging still seemed broken, but I was able to debug the asm with layout reg. I used set $rip = ... with a copy-pasted address to get out of the _mm_pause() loop after attaching and hitting control-C.
We are facing an error when running proccess
Pid 4845 in trap loop, signal 11
Memory fault(coredump)
Here the output of the command gdb bch core
bscs2app:/apps/bscsadm/bscs/SK_20200202 ] gdb bch core
HP gdb 6.3 for HP Itanium (32 or 64 bit) and target HP-UX 11iv2 and 11iv3.
Copyright 1986 - 2011 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 6.3 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
warning: Load module /apps/bscsadm/bscs/bin/hpux11_31.x/bch has been stripped.
Debugging information is not available.
(no debugging symbols found)...
Core was generated by `bch'.
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object
(no debugging symbols found)..."/apps/bscsadm/bscs/SK_20200202/./": can't read symbols: File format not recognized.
warning: Error in reading symbols from ... skipping
warning: Load module /oracle/ora111/lib/libnnz11.so has been stripped.
Debugging information is not available.
#0 0xc0000000000d2120:0 in BV_overlap+0x2e0 ()
from /usr/lib/hpux64/dld.so
(gdb)
If installing the latest HP-UX Linker, Libraries and Tools patch does not solve your problem, you should report it to HPE.
After doing some programming assignments for school, I decided to start working on some side projects I had in mind. I decided to install vim on Windows and link it properly using Cygwin. I installed gcc and gdb at first, to try to see if everything worked. I made a quick C file that had a few printf's so I could step into them using gdb.
I can set a breakpoint in main, run the program, get the first printf, but the moment I try to step into the next line, an error appears.
(gdb) step
_sigfe_puts () at sigfe.s:7019
7019 sigfe.s: No such file or directory.
I thought I didn't install gdb properly, so I reinstalled to no luck. I tried using UltraGDB to see if it would help, but the same thing happened, this time giving me a much clearer error.
Can't find a source file at "C:/cygwin64/cygwin/src/cygwin/cygwin-2.8.0/cygwin-2.8.0-1.x86_64/build/x86_64-pc-cygwin/winsup/cygwin/sigfe.s"
Locate the file or edit the source lookup path to include its location.
I had a suspicion it had to do with permissions, so I tried to look up said directory and turns out it really does not exist. C:/cygwin64/ does not have a cygwin folder, much less a subfolder called src and so on. What I did find is that there is a folder called x86_64-pc-cygwin in the cygwin64/usr but it does not have a winsup folder at all.
I'm lost as to what I can do now to fix this error, it's been annoying me for the past few days and have not found any fixes regarding this. I assume GDB is looking for this file in the wrong place, but if I have gdb installed using the Cygwin setup executable then shouldn't this be working anyway? Any help would be appreciated, thank you.
Complete test run w/error:
$ gdb ./test
GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./test...done.
(gdb) break main
Breakpoint 1 at 0x1004010ed: file test.c, line 6.
(gdb) run
Starting program: /home/User/test
[New Thread 13236.0x4c0]
[New Thread 13236.0x824]
[New Thread 13236.0x3078]
[New Thread 13236.0x374]
Breakpoint 1, main () at test.c:6
6 printf("Hello\n");
(gdb) step
_sigfe_puts () at sigfe.s:7019
7019 sigfe.s: No such file or directory.
(gdb)
7020 in sigfe.s
(gdb)
7023 in sigfe.s
(gdb)
_sigfe () at sigfe.s:19
19 in sigfe.s
(gdb)
20 in sigfe.s
(gdb)
21 in sigfe.s
.
.
.
(stops responding after various steps)
sigfe.s is a source file dynamically created during cygwin build.
It is present in the build tree:
$ find . -iname "*sigfe*"
./x86_64-unknown-cygwin/winsup/cygwin/sigfe.o
./x86_64-unknown-cygwin/winsup/cygwin/sigfe.s
and it seems the only file with such characteristics
$ find . -iname "*.s"
./x86_64-unknown-cygwin/winsup/cygwin/sigfe.s
In theory it should be included in the cygwin-debuginfo package
$ cygcheck -l cygwin-debuginfo | grep -i "s$"
/usr/src/debug/cygwin-2.8.1-0.1/newlib/libc/machine/x86_64/memcpy.S
/usr/src/debug/cygwin-2.8.1-0.1/newlib/libc/machine/x86_64/memset.S
/usr/src/debug/cygwin-2.8.1-0.1/newlib/libc/machine/x86_64/setjmp.S
You can highlight the issue on the cygwin mailing list.
https://cygwin.com/cygwin/lists.html
I can't seem to get readable debugging output for programs compiled with GCC 4.7 MacPorts build.
I've tried with both GDB 6.3 and GDB 7.3 and each have their own problems.
Try with GDB 7.3 (MacPorts)
With GDB 7.3 I get the following output on startup:
$ ggdb ./test
GNU gdb (GDB) 7.3
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin11.4.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
Reading symbols from /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test...Reading symbols from /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test.dSYM/Contents/Resources/DWARF/test...done.
done.
Running and triggering an assertion results in an unreadable stack trace:
(gdb) r
Starting program: /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
main
Assertion failed: (false), function lock, file main.cpp, line 168.
Program received signal SIGABRT, Aborted.
0x00007fff8ede282a in ?? ()
(gdb) bt
#0 0x00007fff8ede282a in ?? ()
#1 0x00007fff9a273a9c in ?? ()
#2 0x00007fff6af00690 in ?? ()
#3 0x0000003000000030 in ?? ()
#4 0x00007fffffffffdf in ?? ()
#5 0x000000010b305840 in ?? ()
#6 0x00007fff6af006d0 in ?? ()
#7 0x00007fff9a2a65de in ?? ()
#8 0x0000000000000000 in ?? ()
Try with GDB 6.3 (built-in)
According to this answer I should use GDB 6.3. However that leads to a different set of problems. During startup I get a bunch of errors:
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov 3 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility.cc".
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility-debug_list.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility-debug_list.cc".
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility-debug_list-2.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility-debug_list-2.cc".
This is what I see if an assertion is triggered and I try to get a backtrace:
Assertion failed: (false), function lock, file main.cpp, line 168.
Program received signal SIGABRT, Aborted.
0x00007fff8ede282a in __kill ()
(gdb) bt
#0 0x00007fff8ede282a in __kill ()
#1 0x00007fff9a273a9c in abort ()
#2 0x00007fff9a2a65de in __assert_rtn ()
Die: DW_TAG_unspecified_type (abbrev = 19, offset = 423)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Die: DW_TAG_unspecified_type (abbrev = 19, offset = 423)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Dwarf Error: Cannot find type of die [in module /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test.dSYM/Contents/Resources/DWARF/test]
According to this answer (which quotes the GCC 4.5 manual) I should use the -gdwarf-2 -gstrict-dwarf options.
I followed this advice. My build command looks like this:
g++ -o run-test -std=c++0x -Wall -Wextra -Werror -gdwarf-2 -gstrict-dwarf -g2 -O0 -I/opt/local/include main.cpp
However, it doesn't fix any of the aforementioned problems.
For the record: I'm on OS X Lion.
Does anyone know how to fix this?
According to the g++ man pages you should use -ggdb to generate debug symbols for gdb. BTW, just using -g always generated good symbols for gdb in my experience (on linux, windows (mingw) and mac).
The warnings from your MacPorts gdb 7.3 session are for load commands 0x24 (LC_VERSION_MIN_MACOSX) and 0x26 (LC_FUNCTION_STARTS). These are new load commands but are not essential for debugging - the warnings are harmless. The fact that your session lacks any symbolic information is maybe because of ASLR? It's been years since that was introduced into the system for user land debugging but that's what the debugger output can look like if it doesn't know that everything slid around in memory at runtime.
Have you tried using lldb? The version provided in Xcode 4.5 is really quite nice. It is the debugger that Apple is currently supporting and developing actively, and it should work with the DWARF output by more recent compilers correctly. The command syntax is a little different than gdb (although there are many command shortcuts provided that make it familiar to gdb users), there's a table of gdb/lldb command equivalences provided over at http://lldb.llvm.org/lldb-gdb.html. Give it a try, you might like it.
I tried to compile a 7.x Version of gdb without any luck.
I codesigned the executable(http://sourceware.org/gdb/wiki/BuildingOnDarwin).
With following version there were these problems.
7.5,7.4,git clone: unknown load command 0x2a (and others) for my application and different system libraries when starting gbd. When trying to print a vector for example i always get:
Could not find the frame base for "main(int, char**)"
7.3 (macports and from gdb-website): on starting the application it fails to set the breakpoint and continues to run.
(gdb) start
Temporary breakpoint 1 at 0x100000950: file ../src/main.cpp, line 15.
Starting program: [...]
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x2a
BFD: unable to read unknown load command 0x26
Error in re-setting breakpoint 1: Cannot access memory at address 0x100000950
[application continues]
I used the system llvm-gcc, gcc4.7 and svn-gcc4.8 to compile.
Has anybody succeeded in installing gdb on Mountain Lion?
i installed gdb 7.5 on mountain lion without problems...
those steps might help you: ./configure --prefix=/usr/local
--enable-targets=x86_64-apple-darwin10 --enable-64-bit-bfd --disable-werror --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
then make install gdb.
create your own certificate like discribed here and sign the gdb
http://sourceware.org/gdb/wiki/BuildingOnDarwin
you have to explicitly state: codesign -s gdb-cert /usr/local/gdb
before you sign the gdb make sure you already set your certificate
to trusted. also close the keychain before signing your gdb.
hope this also works for your
I resolved this issue by following the steps tried here: http://coding.derkeiler.com/Archive/Ada/comp.lang.ada/2012-09/msg00305.html
Steps
sudo chgrp procmod /usr/local/bin/gdb
sudo chmod g+s /usr/local/bin/gdb
Edit /System/Library/LaunchDaemons/com.apple.taskgated.plist and add +p argument to taskgated process
Force kill taskgated process (it will restart)
Try again
Other links:
https://blogs.oracle.com/dns/entry/understanding_the_authorization_framework_on
it doesn't seem to work for me... same issue as with the default homebrew settings
v1:src zeph$ brew install gdb
==> Downloading http://ftpmirror.gnu.org/gdb/gdb-7.5.tar.bz2
Already downloaded: /Library/Caches/Homebrew/gdb-7.5.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/gdb/7.5 --with-python=/usr --with-system-readline --enable-targets=x86_64-apple-darwin10 --enable-64-bit-bfd --disable-werror --build=x86_64-apple-darwin10 --hos
==> make
==> make install
==> Caveats
gdb requires special privileges to access Mach ports.
You will need to codesign the binary. For instructions, see:
http://sourceware.org/gdb/wiki/BuildingOnDarwin
==> Summary
/usr/local/Cellar/gdb/7.5: 62 files, 9.3M, built in 119 seconds
v1:src zeph$ codesign -s gdb-cert /usr/local/Cellar/gdb/7.5/bin/gdb
v1:src zeph$ /usr/local/Cellar/gdb/7.5/bin/gdb --args /Users/zeph/tmp/CouchBase/src/install/bin/memcached -d -u root -P /tmp/0libmemcached_memc.pid -t 1 -p 11221 -U 11221 -m 128
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
BFD: /Users/zeph/tmp/CouchBase/src/install/bin/memcached: unknown load command 0x29
BFD: /Users/zeph/tmp/CouchBase/src/install/bin/memcached: unknown load command 0x29
Reading symbols from /Users/zeph/tmp/CouchBase/src/install/bin/memcached...done.
(gdb) run
Starting program: /Users/zeph/tmp/CouchBase/src/install/bin/memcached -d -u root -P /tmp/0libmemcached_memc.pid -t 1 -p 11221 -U 11221 -m 128
Unable to find Mach task port for process-id 28755: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb)
k, I had to re-sign it after having TRUSTED the certificate all across the board
codesign -fs gdb-cert /usr/local/Cellar/gdb/7.5/bin/gdb
There were two issues in the OP's question. The one regarding signing the executable or modifying taskgated and using setgid procmod has been covered. The second issue is the warnings about unknown load commands. I too ran into this and after a bunch of searching came across the following patches, that fix it:
https://gist.github.com/davidbalbert/4197567