Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12590 Discussions

Differences between dcc/objdump and nios2-elf-gcc/nios2-elf-objdump?

Altera_Forum
Honored Contributor II
1,421 Views

Hi! 

I'm trying to get some information out of the elf-file but it seems that there are some differences between the regular tools and the tools with nios2-elf- prefix. 

 

 

Before I start to explain my problem - Here's the (nonsense-) code I am compiling with both gcc editions: 

 

test.c 

#include "testb.h" int myGlobalVar = 2; volatile int myVolatileVar = 4; myStruct globalStruct = {2, 3, 4}; int main() { int bla = funca(13, 44); double yeah = funcb(); bla += 2; return bla; } 

 

testb.h 

int funca(int myParam1, int myParam2) { int jack = (myParam1 + 32) - myParam2; jack += (64 + myParam2); return jack; } typedef struct myStruct { int lorem; double ipsum; char dolor; } myStruct; double funcb() { long xmas = 8; float easter = (float)xmas + 8.1f; return (double)xmas; } 

 

 

If I compile the code with the regular gcc using 

$ gcc -g ./test.c -otest.exe 

and create an object dump using 

$ objdump -g ./test.exe > objdump.txt 

I get this: 

./test.exe: file format pei-i386 /cygdrive/c/Documents and Settings/xyz/Desktop/./test.c: typedef int32 int; typedef int8 char; typedef int32 long int; typedef uint32 unsigned int; typedef uint32 long unsigned int; typedef int64 long long int; typedef uint64 long long unsigned int; typedef int16 short int; typedef uint16 short unsigned int; typedef int8 signed char; typedef uint8 unsigned char; typedef float float; typedef double double; typedef float96 long double; typedef struct %anon1 { /* size 8 */ int real; /* bitsize 32, bitpos 0 */ int imag; /* bitsize 32, bitpos 32 */ } complex int; typedef complex float0 complex float; typedef complex float0 complex double; typedef complex float0 complex long double; typedef void void; typedef char *__builtin_va_list; typedef bool32 boolean; typedef boolean _Bool; /* file ./testb.h line 2 addr 0x401050 */ /* file ./testb.h line 3 addr 0x401056 */ /* file ./testb.h line 4 addr 0x401064 */ /* file ./testb.h line 6 addr 0x401070 */ /* file ./testb.h line 7 addr 0x401073 */ /* file ./testb.h line 15 addr 0x401075 */ /* file ./testb.h line 16 addr 0x40107b */ /* file ./testb.h line 17 addr 0x401082 */ /* file ./testb.h line 18 addr 0x401090 */ /* file ./testb.h line 19 addr 0x401093 */ int main () { /* 0x401095 */ { /* 0x401095 */ double yeah /* 0xfffffff0 */; int bla /* 0xfffffffc */; /* file ./test.c line 8 addr 0x401095 */ /* file ./test.c line 8 addr 0x4010ba */ /* file ./test.c line 9 addr 0x4010bf */ /* file ./test.c line 10 addr 0x4010d6 */ /* file ./test.c line 11 addr 0x4010de */ /* file ./test.c line 12 addr 0x4010e4 */ /* file ./test.c line 13 addr 0x4010e7 */ } /* 0x4010e9 */ } /* 0x4010e9 */ ./testb.h: int funca (int myParam1 /* 0x8 */, int myParam2 /* 0xc */) { /* 0x401050 */ { /* 0x401050 */ int jack /* 0xfffffffc */; } /* 0x401075 */ } /* 0x401075 */ struct myStruct { /* size 24 id 2 */ int lorem; /* bitsize 32, bitpos 0 */ double ipsum; /* bitsize 64, bitpos 64 */ char dolor; /* bitsize 8, bitpos 128 */ }; typedef struct myStruct /* id 2 */ myStruct; double funcb () { /* 0x401075 */ { /* 0x401075 */ float easter /* 0xfffffff8 */; long int xmas /* 0xfffffffc */; } /* 0x401095 */ } /* 0x401095 */ ./test.c: int myGlobalVar /* 0x402000 */; int volatile myVolatileVar /* 0x402004 */; myStruct globalStruct /* 0x402008 */; 

 

 

But if I compile the code with the regular gcc using 

$ nios2-elf-gcc -g ./test.c -otest.exe 

and create an object dump using 

$ nios2-elf-objdump -g ./test.exe > objdump.txt 

I get this: 

./test.exe: file format elf32-littlenios2 

 

 

Why is there no information about the variables, structs and so on?
0 Kudos
8 Replies
Altera_Forum
Honored Contributor II
520 Views

The debug sections will be in completely different formats. 

Quite likely the one used by the nios doesn't actually contain the source info.
0 Kudos
Altera_Forum
Honored Contributor II
520 Views

Is it possible to get that information in any other way?

0 Kudos
Altera_Forum
Honored Contributor II
520 Views

What are you actually trying to do??

0 Kudos
Altera_Forum
Honored Contributor II
520 Views

I'd like to get information about variables (name, type, address) and structs (name and type of included variables + bitsize and bitpos).

0 Kudos
Altera_Forum
Honored Contributor II
520 Views

As I asked earlier, what are you actually trying to do? 

Various commands will give some of that information. 

Maybe you don't actually need other parts. 

I've never really worried about structure member offsets - even though I often look at hexdumps of structures. 

If you are putting code through several compilers, it can be worth doing a compile-time check of the sizes of shared structures - but the numbers are usually irrelevant. 

 

If you are feeling adventurous look into the gcc/gdb code/docs and work out the format of the debug sections.
0 Kudos
Altera_Forum
Honored Contributor II
520 Views

I don't want to put the code through several compilers. 

I compile it with the nios2-elf-gcc and want to access the variables from outside (e.g. with another nios2 processor). For this purpose I need the address and the type of each variable (as the output quoted above from regular objdump).
0 Kudos
Altera_Forum
Honored Contributor II
520 Views

No... Just compile your other program with the relevant .h files, and add: 

-Wl,--just-symbols=$(OBJ_DIR)/prog_2.elf 

to the build so that it has all the sybols available. 

Or extract a subset of the symbols using nm or objdump -t (or read the elf symbol table directly yourself). 

 

I specify that (and -Wl,--no-warn-mismatch) to link a linux ppc binary with the symbol table of the nios code. It also gets the nios code+data embedded into its data areas (generated by a couplye of objcopy commands).
0 Kudos
Altera_Forum
Honored Contributor II
520 Views

Thank you for this information, 

 

but I don't want to recompile the code for the second processor with the necessary structure definitions. The second processor shouldn't know anything about the data at the memory addresses. But I need this information to access the correct memory positions. For that I wanted to use the output of "nios2-elf-objdump -g".
0 Kudos
Reply