Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] objdump/addr2line problems


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.


At 12:36 PM 6/16/2003 -0700, Anthony Green wrote:

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

Is anybody working on this problem?


Anthony Green <green@xxxxxxxxxx>
Red Hat, Inc.

cdt-dev mailing list

Back to the top