#30970: arm-none-eabi-gdb: remote 'g' packet reply is too long -------------------------------------+-------------------------------------- Reporter: ben.m.cochran@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: arm-none-eabi-gdb -------------------------------------+-------------------------------------- I've installed the MacPorts version of the GNU ARM Toolchain (arm-none- eabi-gcc and arm-none-eabi-gdb) and am running into a problem with the GDB debugger. I'm taking a class where we use the Stellaris LM3S8962 evaluation board (Cortex-M3) and a fellow classmate has installed via compiling arm-none- eabi-* using CodeSourcery Lite and GDB works fine. I chronicled my adventure in a StackOverflow posting, the main issue I am having is in the "UPDATES" and "UPDATES 2" section of my question here: http://stackoverflow.com/questions/7053067/arm-none-eabi-gdb-and-openocd- malformed-response-to-offset-query-qoffsets Essentially, when I connect to the remote GDB target (openocd) GDB claims after presenting a compiled .axf file: {{{ (gdb) target remote localhost:3333 Remote debugging using localhost:3333 Remote 'g' packet reply is too long: 0080004000000000040000220f0000002833405451332abc009600a4d2b86092c0c11 8c03040d6f0284dbb93204b40c2000000000c010020ffffffff5504 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000020000001 }}} Searching the internet, it seems to suggest that gdb is not interpreting the ARM architecture correctly. However, none of the prescribed workarounds (setting architecture manually, or delaying the symbol file loading) holds. Compiling with arm-none-eabi-gcc and uploading to the target with openocd works flawlessly. I am in the process of trying to compile the CodeSourcery Lite toolchain but am having dependency issues because most of my compiler tools live in MacPorts. Do you think this is a problem with the port itself? Seems strange that another toolchain (with the same ABI) and the same OpenOCD works fine... -- Ticket URL: <https://trac.macports.org/ticket/30970> MacPorts <http://www.macports.org/> Ports system for Mac OS