Re: [cdt-dev] objdump/addr2line problems

[Chris Songer <songer@xxxxxxxxxxxxx>]

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