This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Greetings, I am not sure if this is the proper place to ask, but I have been playing with the msp430-elf port of gcc/binutils/newlib/gdb and I have been presenting an issue for a while now. Last September, I e-mailed the GDB mailing list but the message went largely ignored. The bug report I filed with GDB went ignored as well and remains open. To be honest, I am not sure if the issue is with GDB, binutils or gcc, but GDB is unable to read dwarf line numbers from binaries generated by binutils. When asking about it in the GDB IRC channel, I was told it was because there was some conflicting information on how these symbols were generated. readelf is able to correctly identify the symbols because it uses a different algorithm from GDB when reading them. I am building the toolchain following the standard build procedure of binutils -> gcc-stage1 -> newlib -> gcc -> gdb When building newlib and disassembling some of the files I get this message: $ msp430-elf-objdump -S /usr/msp430-elf/lib/crtn.o >/dev/null msp430-elf-objdump: Dwarf Error: Line info data is bigger (0xfffffffc) than the section (0x43) which seems to relate to [1], but I ignored it, considering that no linker script should be utilized to build this kind of thing at the moment (I believe). Furthermore, gdb is able to read line numbers from these portions of the executable, it is the main body of the program where GDB fails to do anything. I am building the toolchain with pristine sources using: [binutils] ../configure --target=msp430-elf \ --prefix=/usr \ --disable-nls \ --program-prefix=msp430-elf- \ --enable-multilib \ --disable-werror \ --with-sysroot=/usr/msp430-elf \ --host=${CHOST} \ --build=${CHOST} \ --disable-shared \ --enable-lto make configure-host make make install [gcc-stage1] export CFLAGS_FOR_TARGET="-Os -pipe" export CXXFLAGS_FOR_TARGET="-Os -pipe" ../configure \ --prefix=/usr \ --program-prefix=msp430-elf- \ --target=msp430-elf \ --host=$CHOST \ --build=$CHOST \ --disable-shared \ --disable-nls \ --disable-threads \ --enable-languages=c \ --enable-multilib \ --without-headers \ --with-newlib \ --with-local-prefix=/usr/msp430-elf \ --with-sysroot=/usr/msp430-elf \ --with-as=/usr/bin/msp430-elf-as \ --with-ld=/usr/bin/msp430-elf-ld \ --disable-libgomp make all-gcc make install-gcc [newlib] export CFLAGS_FOR_TARGET="-Os -g -ffunction-sections -fdata-sections" ../configure \ --prefix=/usr \ --target=msp430-elf \ --disable-newlib-supplied-syscalls \ --enable-newlib-reent-small \ --disable-newlib-fseek-optimization \ --disable-newlib-wide-orient \ --enable-newlib-nano-formatted-io \ --disable-newlib-io-float \ --enable-newlib-nano-malloc \ --disable-newlib-unbuf-stream-opt \ --enable-lite-exit \ --enable-newlib-global-atexit \ --disable-nls make -j1 make install [gcc] export CFLAGS_FOR_TARGET="-Os -pipe" export CXXFLAGS_FOR_TARGET="-Os -pipe" ../configure \ --prefix=/usr \ --program-prefix=msp430-elf- \ --target=msp430-elf \ --host=${CHOST} \ --build=${CHOST} \ --disable-shared \ --disable-nls \ --disable-threads \ --enable-languages=c,c++ \ --enable-multilib \ --with-system-zlib \ --with-local-prefix=/usr/msp430-elf \ --with-sysroot=/usr/msp430-elf \ --with-as=/usr/bin/msp430-elf-as \ --with-ld=/usr/bin/msp430-elf-ld \ --disable-libgomp \ --enable-interwork \ --enable-addons make all-gcc all-target-libgcc make install-gcc install-target-libgcc [gdb] ../configure \ --prefix=/usr \ --without-guile \ --target=msp430-elf \ --host=${CHOST} \ --build=${CHOST} \ --with-sysroot=/usr/msp430-elf \ --disable-nls \ --with-python=/usr/bin/python2 \ --with-system-readline \ --disable-werror \ --disable-tui make make install The GDB bug report can be found at [2] and the original mailing list message at [3]. I have been told that TI's pre-compiled distribution of the toolchain can handle line numbers in dwarf data just fine. Is there a patch am I missing or some parameter am I not passing correctly to the configure script? Thank you for your time. Cheers, Orlando. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=17940 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=19033 [3] https://sourceware.org/ml/gdb/2015-09/msg00030.html
Attachment:
signature.asc
Description: OpenPGP digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |