[MacPorts] #30970: arm-none-eabi-gdb: remote 'g' packet reply is too long

[MacPorts]

#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