Hi,

I've just started playing with the gcc port for msp430.

I've compiled and linked my program with:

msp430-gcc test.c -o test -I /cygdrive/c/mspgcc/msp430/include
-mmcu=msp430x449 -g

But when I run msp430-gdb, I get, when I run "file test" :

"test": not in executable format: File format not recognized

The file "test" has the keyword ELF in it, so I would guess it's the
correct format. I don't understand why msp430-gdb would have a problem
with it. msp430-gdb -v gives me:

GNU gdb 6.0 ...

This GDB was configured as "--host=i686-pc-cygwin --target=msp430".

And msp-gcc is the latest version from Sourceforge.

Anybody have an idea what the problem might be here?

Thanks,
Martin.

On 2006-05-18, Martin <u...@martin-collins.de> wrote:

[...]

You didn't like the response I posted when you asked this on
the msp430-gcc mailing list yesterday?

-- 
Grant Edwards                   grante             Yow!  My mind is making
                                  at               ashtrays in Dayton....
                               visi.com            

Hi,

hadn't seen your reply! My messages have to be vetted for the mailing
list and so take a little longer. As you can see I tried "file test"
and msp430-gdb replies that it doesn't recognise the format. This
doesn't make any sense since msp_gcc created the executable.

Cheers,
Martin.

On 2006-05-18, Martin <u...@martin-collins.de> wrote:

> hadn't seen your reply! My messages have to be vetted for the
> mailing list and so take a little longer. As you can see I
> tried "file test"

Is the name of the object file created by msp430-gcc "test" or
"test.elf"?  The command line you showed in your posting on the
mailing list was creating "test.elf", but then you were trying
to do things with a file named "test".

Where did the file "test" come from?

> and msp430-gdb replies that it doesn't recognise the format.
> This doesn't make any sense since msp_gcc created the
> executable.

That depends on which command line you really used -- the one
you posted on the mailing list, or the one you posted here.

What do the following commands display?

    msp430-objdump --section-headers test
    
    msp430-objdump --section-headers test.elf

-- 
Grant Edwards                   grante             Yow!  PEGGY FLEMING is
                                  at               stealing BASKET BALLS to
                               visi.com            feed the babies in VERMONT.

Op 18 May 2006 10:54:45 -0700 schreef Martin:

> Hi,
> 
> hadn't seen your reply! My messages have to be vetted for the mailing
> list and so take a little longer. As you can see I tried "file test"
> and msp430-gdb replies that it doesn't recognise the format. This
> doesn't make any sense since msp_gcc created the executable.
> 
> Cheers,
> Martin.

In a *NIX environment test is a reserved word: man test
So you might have use another name after -o
or use './test' at the prompt.
HTH, I don't suscribet do a msp430 mailing list.

-- 
Coos

On 2006-05-18, Coos Haak <c...@hccnet.nl> wrote:

>> hadn't seen your reply! My messages have to be vetted for the mailing
>> list and so take a little longer. As you can see I tried "file test"
>> and msp430-gdb replies that it doesn't recognise the format. This
>> doesn't make any sense since msp_gcc created the executable.
>
> In a *NIX environment test is a reserved word: man test

That only matters if you're trying to run a program named
"test" from the shell without specifying a path.  Some shells
have a built-in named "test". Other shells will find the "test"
executable in /usr/bin.

However that has absolutely no impact on creating or using a
file named "test" in other contexts.

> So you might have use another name after -o

Using a file named "test" is perfectly fine.  

For non-native ELF files, I generally use a ".elf" suffix, but
that's purely a matter of personal taste: Unix doesn't care
least if I want to name a file "test" or "test.elf".

> or use './test' at the prompt.

It doesn't matter.  It's not a program he's trying to execute
from a shell prompt, so there's no difference between using
"test" and using "./test":

$ echo "hi there" >test

$ cat test
hi there

$ file test
test: ASCII text

$ wc test
1 2 9 test

$ tr '[a-z]' '[A-Z]' <test
HI THERE

-- 
Grant Edwards                   grante             Yow!  Of course, you
                                  at               UNDERSTAND about the PLAIDS
                               visi.com            in the SPIN CYCLE --

On 2006-05-18, Grant Edwards <g...@visi.com> wrote:

>> So you might have use another name after -o
>
> Using a file named "test" is perfectly fine.  
>
> For non-native ELF files, I generally use a ".elf" suffix, but
> that's purely a matter of personal taste: Unix doesn't care
> least if I want to name a file "test" or "test.elf".

After thinking about it more, I do remember that many years
ago, the Cygwin-hosted Gnu linker had a bug where if you
specified a filename without a "suffix", it would create an
output file with ".exe" tacked onto the name of the file even
though the file definitely wasn't a ".exe" file.  That fun
little bit of brain-damage caused a lot of Makefiles to break.
But, I thought that was fixed a long time ago.  

In any case, I don't see how that problem would have caused the
symptoms the OP is reporting.

-- 
Grant Edwards                   grante             Yow!  What's the MATTER
                                  at               Sid?... Is your BEVERAGE
                               visi.com            unsatisfactory?

Hi,

yeah I tried naming the binary test.elf, test and test_1 just in case.
I simply renamed the same file each time.

I ran "msp430-objdump --section-headers test_1":

test_1:     file format elf32-msp430

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000780  00001100  00001100  00000094  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000002  00000200  00001880  00000814  2**1
                  CONTENTS, ALLOC, LOAD, DATA
  2 .vectors      00000020  0000ffe0  0000ffe0  00000816  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .stab         00001bcc  00000000  00000000  00000838  2**2
                  CONTENTS, READONLY, DEBUGGING
  4 .stabstr      00002879  00000000  00000000  00002404  2**0
                  CONTENTS, READONLY, DEBUGGING

That certainly indicates that the binary file is ok.

Cheers,
Martin.

On 2006-05-19, Martin <u...@martin-collins.de> wrote:

> yeah I tried naming the binary test.elf, test and test_1 just
> in case. I simply renamed the same file each time.
>
> I ran "msp430-objdump --section-headers test_1":
>
> test_1:     file format elf32-msp430
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00000780  00001100  00001100  00000094  2**1
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .data         00000002  00000200  00001880  00000814  2**1
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .vectors      00000020  0000ffe0  0000ffe0  00000816  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   3 .stab         00001bcc  00000000  00000000  00000838  2**2
>                   CONTENTS, READONLY, DEBUGGING
>   4 .stabstr      00002879  00000000  00000000  00002404  2**0
>                   CONTENTS, READONLY, DEBUGGING
>
> That certainly indicates that the binary file is ok.

That looks right.  If msp430-objdump recognizes the file as an
MSP430 ELF file and msp430-gdb doesn't, then msp430-gdb must be
broken.

Can cut/paste a sample gdb session into a posting?

-- 
Grant Edwards                   grante             Yow!  .. bleakness....
                                  at               desolation.... plastic
                               visi.com            forks...

Hi,

here's a copy of what happens:

$ msp430-gdb --se=test_1
GNU gdb 6.0
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "--host=i686-pc-cygwin
--target=msp430"..."/home/tst/
LCD/test_1": not in executable format: File format not recognized
(gdb) file test_1
"/home/tst/LCD/test_1": not in executable format: File format not
recognized
(gdb)



Is it possible that the new version of msp-gcc isn't compatible with
msp-gdb?
I downloaded it all  from Sourceforge 3 days ago.

Cheers,
Martin.