Re: Mapping C code to generated asm code

[Ron McCall]

On Wed, Jan 11, 2006 at 12:03:42PM -0600, Perry Smith wrote:
> Is there a way to get some type of debugging output that tells me  
> what line of C code produced what lines of asm code?

How about $TARGET-objdump --disassemble --source?

Ron

Intermixing powerpc-eabi and powerpc-linux C code

[Ron McCall]

Hi!

Does anyone happen to know if it is possible to link
(and run) C code compiled with a powerpc-eabi targeted
gcc with C code compiled with a powerpc-linux targeted
gcc?  The resulting program would be run on a PowerPC
Linux system (ELDK 4.0).

In this case, main() would be compiled by
powerpc-linux-gcc while a test driver and all code to
be tested would be compiled by powerpc-eabi-gcc. 
Everything would be linked using powerpc-linux-gcc.  

The call from Linux-land to eabi-land would not need
to pass arguments nor return anything and nothing
would need to be shared between the two pieces of
code.

None of the powerpc-eabi code will depend on any
libraries or other external code, it will all be
completely self-contained.

Thanks!

Ron McCall

Re: Intermixing powerpc-eabi and powerpc-linux C code

[Ron McCall]

I guess I should have also mentioned that the
resultant program will be run under gdb, with a script
setting breakpoints, running, examining variables,
etc.

--- Paul Brook <[EMAIL PROTECTED]> wrote:

> > The call from Linux-land to eabi-land would not
> need
> > to pass arguments nor return anything and nothing
> > would need to be shared between the two pieces of
> > code.
> 
> So basically you can replace the whole thing with
> sleep(1); and noone would be 
> any the wiser.
> 
> Paul
> 

Re: Intermixing powerpc-eabi and powerpc-linux C code

[Ron McCall]

You make a good point about the linker aspect but I was first most
concerned about the code generation differences, if any. 

However, you are absolutely correct!  A test is in order.  I whipped up
a quick test program and was able to successfully compile, link and run
it, so it does indeed work!  Thanks!

On Thu, Jun 01, 2006 at 04:08:14PM -0700, Mike Stump wrote:
> This is a linker question, we don't do linkers here.  In particular,
> the relocs have to be compatible, if you want to do reloc  processing.
> You can use ld and resolve all the relocs and just slam  in the bytes,
> but then, you're not using gcc to link per se.
> 
> Why not just try it out and see?

DWARF2 DW_TAG_base_type for void?

[Ron McCall]

Hi,

I have some third party code with the following
typedef:

typedef void VOID;

I found in the readelf dump of the .debug_info section
that the corresponding DW_TAG_typedef entry had no
DW_AT_type attribute (which usually links to a
DW_TAG_base_type entry).  It seems that gcc does not
emit a DW_TAG_base_type entry for void.  Is that
intentional?

In this program there are only DW_TAG_pointer_type
entries linking to this DW_TAG_typedef entry.  Without
the typedef, I would have expected (perhaps naively)
that the DW_TAG_pointer_type would link to a
DW_TAG_base_type for void (in the case of a void *
pointer type).  Is that not the case?

I am using gcc 4.0.3 and binutils 2.16.1 in case that
matters.

Just curious.

Ron McCall

Re: DWARF2 DW_TAG_base_type for void?

[Ron McCall]

On Wed, Sep 06, 2006 at 07:39:04PM -0400, Daniel Jacobowitz wrote:
> Yes, this is the convention we use.
> 
> Void isn't a base type.  The DWARF 3 standard way to represent this is
> DW_TAG_unspecified_type.

OK, thanks!

Ron