[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] objdump/addr2line problems
|
Hi,
I am hoping that the buildmodel and corresponding toolchain interfaces
fix this for 1.1 or 1.2. We had this issue for Xtensa Xplorer. To fix it
we put in a "cdt tool provider" extension point that provided
these tools.
This is the interface that we ended up adding as a stop gap until it gets
really fixed:
package
org.eclipse.cdt.utils;
import org.eclipse.core.runtime.IPath;
/**
* Some of the CDT needs to run binary tools (addr2line, objdump
* and c++filt are the ones I have found so far.). We need to be
* providing those tools from code that depends on the CDT. This
* is the way we are doing that.
*/
public interface IBinToolProvider
{
/** @return string with the addr2line path */
public String getAddr2line();
/** @return string with the c++filt path */
public String getCPPFilt();
/** @return string with the objdump path */
public String getObjdump();
/** @return the objectdump args (there's been a lot of change here */
public String [] getObjdumpArgs(IPath path);
}
This code was based on 1.0.1. We did not contribute it back just because these issues were being addressed more globally for future releases.
Thanks!
-Chris
At 12:36 PM 6/16/2003 -0700, Anthony Green wrote:
Hello,
EditorUtility.getStorage(IBinary) currently uses "objdump" to extract
info from a binary image. This is really only guaranteed to work for
native binaries. Many people using cross tools prefix the binutils
names with something related to their target (for instance,
mips-elf-objdump). There's a similar problem for addr2line, and perhaps
elsewhere.
Is anybody working on this problem?
AG
--
Anthony Green <green@xxxxxxxxxx>
Red Hat, Inc.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev