Quantcast

TI compiler

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

TI compiler

Bob von Knobloch-2
Hi,
I've been using the 'old' compiler last maintained by P.Bigot(many
thanks to him).
Now I need to make some changes and have installed the new msp430-gcc
6.2.1.16 under OpenSuse 42.1

My small project under the 'old' compiler produced a .text size of 1392
bytes, the 'new' compiler makes a .text of 2160 bytes.

This no longer fits on the target ┬Áproc.

As far as I can see, the 'bloat' is in library funcs (newlib?).
Why the 50% increase and can I mitigate this somehow?
Regards,
Bob von Knobloch.
--
The Sun is out, the sky is blue, it's time to drive the MR2.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

David W. Schultz
On 03/03/2017 05:20 AM, Bob von Knobloch wrote:
> As far as I can see, the 'bloat' is in library funcs (newlib?).
> Why the 50% increase and can I mitigate this somehow?
> Regards,
> Bob von Knobloch.
>

Hard to say without seeing the code. Have you looked at the resulting
file using objdump? If not, that can disassemble the code into something
readable so you can see just what is going on.

--
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

N. Coesel

Op 03/03/2017 om 02:29 PM schreef David W. Schultz:

> On 03/03/2017 05:20 AM, Bob von Knobloch wrote:
>> As far as I can see, the 'bloat' is in library funcs (newlib?).
>> Why the 50% increase and can I mitigate this somehow?
>> Regards,
>> Bob von Knobloch.
>>
> Hard to say without seeing the code. Have you looked at the resulting
> file using objdump? If not, that can disassemble the code into something
> readable so you can see just what is going on.
>
An easier approach is to let the linker generate a map file and compare
between the two compilers. The mapfile shows the size of each object
(source file and imported library functions). It can be code generation
is less efficient or libraries are bigger. The original MSP430GCC C
libraries are very compact so it wouldn't surprise me if it turns out a
different library is the cullprit.

N. Coesel

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

nick clifton
In reply to this post by David W. Schultz
Hi Bob,

> As far as I can see, the 'bloat' is in library funcs (newlib?).

If the bloat is indeed in the library funcs why not just compile with
gcc and then link in the old, mspcc C library instead of newlib ?

Cheers
  Nick




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Bob von Knobloch-2
In reply to this post by David W. Schultz
On 03/03/17 14:29, David W. Schultz wrote:

> On 03/03/2017 05:20 AM, Bob von Knobloch wrote:
>> As far as I can see, the 'bloat' is in library funcs (newlib?).
>> Why the 50% increase and can I mitigate this somehow?
>> Regards,
>> Bob von Knobloch.
>>
>
> Hard to say without seeing the code. Have you looked at the resulting
> file using objdump? If not, that can disassemble the code into something
> readable so you can see just what is going on.
>
Yes, it shows (as does the .map file) that the .text corresponding to my
source is approx. the same size for both compilers, but that the very
basic library functions that get pulled in (add, subtract etc.) are
producing much more code than in the old version.
I have tested different optimisation switches, but always get the same
resulting code size.

Bob


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Yama Ploskonka-2
I "thought" something like that was happening to me, but didn't follow
through. For operating system compatibility reasons I decided a while back
to just keep using the legacy one, it works well for the simple things that
I do, also some tool I downloaded from TI was a terrible bloat itself in
the computer at that moment, and I really didn't need whatever GUI features
it offered, if any, or why it needed so much space (very early SSD, 1.5 GB
available space total).

Too many words to say, again, thanks to P.Bigot! your stuff is still being
used

On Fri, Mar 3, 2017 at 8:08 AM, Bob von Knobloch <[hidden email]> wrote:

> On 03/03/17 14:29, David W. Schultz wrote:
> > On 03/03/2017 05:20 AM, Bob von Knobloch wrote:
> >> As far as I can see, the 'bloat' is in library funcs (newlib?).
> >> Why the 50% increase and can I mitigate this somehow?
> >> Regards,
> >> Bob von Knobloch.
> >>
> >
> > Hard to say without seeing the code. Have you looked at the resulting
> > file using objdump? If not, that can disassemble the code into something
> > readable so you can see just what is going on.
> >
> Yes, it shows (as does the .map file) that the .text corresponding to my
> source is approx. the same size for both compilers, but that the very
> basic library functions that get pulled in (add, subtract etc.) are
> producing much more code than in the old version.
> I have tested different optimisation switches, but always get the same
> resulting code size.
>
> Bob
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

DJ Delorie
In reply to this post by Bob von Knobloch-2

This has come up before, and here's what's going on... the new
msp430-elf-gcc includes all the code required by the standard, partly
because... well, standards... and partly so that the testsuite can test
everything.  The old msp-gcc made lots of assumptions about how the
compiler would actually be used, and "pre-optimized" the runtime for it.

So you end up with things like "argv handling" when there's no command
line, or "exit closes files" when you never exit.  A big change is using
a float-enabled printf when you don't need it.

I put some notes here, way back when, but they're old, and IIRC it's
been improved even more since then:

http://people.redhat.com/~dj/msp430/size-optimizations.html

Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
support.

Also, if you're REALLY constrained to size, you might consider getting
the crt0.S source file from newlib and modifying it yourself to really
strip out the parts you don't need.  Most embedded code really only
needs to set up the stack and watchdog, then jump to main().

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Peter Bigot-4
In reply to this post by nick clifton
I think it's pretty unlikely msp430-libc would work with upstream gcc,
though I admit I haven't tried it.

http://pabigot.github.io/bsp430/msp430elf.html has some outdated
suggestions for building customized newlib and trimming out functionality
that isn't needed.

Glad to know people are still getting value out of mspgcc.  I'm afraid I
haven't even fired it up for a couple years (mostly doing either ARM
Cortex-M or Node.js these days).

Peter

On Fri, Mar 3, 2017 at 8:03 AM, Nick Clifton <[hidden email]> wrote:

> Hi Bob,
>
> > As far as I can see, the 'bloat' is in library funcs (newlib?).
>
> If the bloat is indeed in the library funcs why not just compile with
> gcc and then link in the old, mspcc C library instead of newlib ?
>
> Cheers
>   Nick
>
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Yama Ploskonka-2
In reply to this post by DJ Delorie
long story short, one of my first mspgcc worked because of a bug, when
later either the bug was fixed in mspgcc or fedora (don't recall which one
exactly), things broke all over, code unusable, docs I had share were
wrong.
But by then I was already married to the MSP430 chips, so I stayed for the
ride, and am generally happy with my choice, though that ESP that uses
arduino code and has full wifi at a cost of around one US dollar per has
more than once made me look again. :-) (but it eats battery power, so
again, MSP430 is better, at least for me)

On Fri, Mar 3, 2017 at 12:30 PM, DJ Delorie <[hidden email]> wrote:

>
> This has come up before, and here's what's going on... the new
> msp430-elf-gcc includes all the code required by the standard, partly
> because... well, standards... and partly so that the testsuite can test
> everything.  The old msp-gcc made lots of assumptions about how the
> compiler would actually be used, and "pre-optimized" the runtime for it.
>
> So you end up with things like "argv handling" when there's no command
> line, or "exit closes files" when you never exit.  A big change is using
> a float-enabled printf when you don't need it.
>
> I put some notes here, way back when, but they're old, and IIRC it's
> been improved even more since then:
>
> http://people.redhat.com/~dj/msp430/size-optimizations.html
>
> Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
> support.
>
> Also, if you're REALLY constrained to size, you might consider getting
> the crt0.S source file from newlib and modifying it yourself to really
> strip out the parts you don't need.  Most embedded code really only
> needs to set up the stack and watchdog, then jump to main().
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Bob von Knobloch-2
In reply to this post by DJ Delorie
On 03/03/17 19:30, DJ Delorie wrote:
>
> This has come up before, and here's what's going on... the new
> msp430-elf-gcc includes all the code required by the standard, partly
> because... well, standards...

> So you end up with things like "argv handling" when there's no command
> line, or "exit closes files" when you never exit.  A big change is using
> a float-enabled printf when you don't need it.
>

>
> Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
> support.
>
> Also, if you're REALLY constrained to size, you might consider getting
> the crt0.S source file from newlib and modifying it yourself to really
> strip out the parts you don't need.  Most embedded code really only
> needs to set up the stack and watchdog, then jump to main().
>

Thanks to all for the input.
This confirms what I suspected regarding newlib.
I will pursue rewriting crt0.S at some stage.
For now, I still can go back to an old OS with mspgcc as a stopgap.
Cheers,

Bob

--
The Sun is out, the sky is blue, it's time to drive the MR2.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Peter Bigot
In reply to this post by DJ Delorie
On Fri, Mar 3, 2017 at 12:30 PM, DJ Delorie <[hidden email]> wrote:

> Also, if you're REALLY constrained to size, you might consider getting
> the crt0.S source file from newlib and modifying it yourself to really
> strip out the parts you don't need.  Most embedded code really only
> needs to set up the stack and watchdog, then jump to main().
>

Be careful with this.  TI's Code Composer compiler originally had a
stripped down crt0 that didn't bother clearing the bss section.  This meant
any static variable definition (including globals) would not necessarily be
cleared on power up.  So if you rely on a variable being null to indicate
that some initialization is necessary your program may or may not work.

The advice is also dubious if you're using C++ as there may be static
constructors that need to be invoked (and yes, modern C++ if used carefully
is appropriate for embedded programming even on constrained chips like
MSP430).

In short, if you muck with the crt0 code be very sure you know the effect
of stripping things out.

Peter

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Orlando Arias
In reply to this post by DJ Delorie
Ugh... Really sorry, hit reply instead of reply list.

Greetings,

Apologies for hijacking this e-mail chain, but I have had issues with
the ``bloat'' in newlib as well. My issue is with internationalization
support in newlib. I have configured and compiled newlib with the
following flags:

  export CFLAGS_FOR_TARGET="-Os -g -ffunction-sections -fdata-sections"
  ../configure \
    --prefix=/usr \
    --target=msp430-elf \
    --disable-newlib-supplied-syscalls \
    --enable-newlib-reent-small \
    --disable-newlib-fseek-optimization \
    --disable-newlib-wide-orient \
    --enable-newlib-nano-formatted-io \
    --disable-newlib-io-float \
    --enable-newlib-nano-malloc \
    --disable-newlib-unbuf-stream-opt \
    --enable-lite-exit \
    --enable-newlib-global-atexit \
    --disable-nls

It was my understanding that --disable-nls would disable
internationalization support. Unfortunately, I am observing the
following behaviour with the attached code:

$ msp430-elf-gcc -Os -o uart uart.c -mmcu=msp430g2553
$ size uart
   text   data    bss    dec    hex filename
    778     16     90    884    374 uart

$ msp430-elf-gcc -Os -o uart uart.c -mmcu=msp430g2553 -DUSE_TOUPPER
$ size uart
   text   data    bss    dec    hex filename
   1476    398     92   1966    7ae uart

The function toupper() is pulling in 382 bytes into .data. This accounts
for 74.6% of this particular microcontroller's SRAM. This is not very
nice. Furthermore, I have not really looked into it, but should this new
data actually be mutable? If not, it could very well go into .rodata and
stay in flash memory.

Ideally, I should be able to disable internationalization support
alltoguether even if it goes against the C and POSIX standards. Is there
any way to actually do that I am missing?

Thank you.

Cheers,
Orlando.

On 03/03/2017 01:30 PM, DJ Delorie wrote:

>
> This has come up before, and here's what's going on... the new
> msp430-elf-gcc includes all the code required by the standard, partly
> because... well, standards... and partly so that the testsuite can test
> everything.  The old msp-gcc made lots of assumptions about how the
> compiler would actually be used, and "pre-optimized" the runtime for it.
>
> So you end up with things like "argv handling" when there's no command
> line, or "exit closes files" when you never exit.  A big change is using
> a float-enabled printf when you don't need it.
>
> I put some notes here, way back when, but they're old, and IIRC it's
> been improved even more since then:
>
> http://people.redhat.com/~dj/msp430/size-optimizations.html
>
> Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
> support.
>
> Also, if you're REALLY constrained to size, you might consider getting
> the crt0.S source file from newlib and modifying it yourself to really
> strip out the parts you don't need.  Most embedded code really only
> needs to set up the stack and watchdog, then jump to main().
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Bob von Knobloch-2
In reply to this post by DJ Delorie
On 03/03/17 19:30, DJ Delorie wrote:
> Also, you can use "msp430-elf-gcc -mintr ..." to minimize the runtime
> support.
Thanks DJ,

I tried -mintr and at least one project produces code that could fit,
thanks (should have RTFM - but finding this was not intuitive).

Now the linker doesn't want to play with me - it cannot find the
"msp430g2231.ld" link file. Curious because the compiler fids "msp430.h"
in the same directory.

It looks like the dir info is not being passed to the linker.
I have tried forcing it with -T<linkscript abs path>, but no joy.
I have my compiler installed at /opt/msp430-gcc/ (I don't want to
clutter /usr/local/bin) and wonder if a hard coded path has been set
somewhere?

I am running on OpenSUSE42.1 (which is 64-bit).
I have tried compiling from source and also installing TI's installer -
the results are the same.
Any one have any ideas ?

Regards,

Bob

--
The Sun is out, the sky is blue, it's time to drive the MR2.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Ben Green
> Now the linker doesn't want to play with me - it cannot find the
> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h"
> in the same directory.

>From my understanding the .h files and the .ld files are not supposed to be in the same directory. When in installed msp430-gcc-support-files-1.198.zip I did this:

cp *.ld /opt/msp430-elf-6.2.1.16/msp430-elf/lib/430/
cp *.h /opt/msp430-elf-6.2.1.16/msp430-elf/include/

> It looks like the dir info is not being passed to the linker.
> I have tried forcing it with -T<linkscript abs path>, but no joy.
> I have my compiler installed at /opt/msp430-gcc/ (I don't want to
> clutter /usr/local/bin) and wonder if a hard coded path has been set
> somewhere?

Now that does seem strange, I would have expected that to work, did you make sure you were passing the argument to the linker and not GCC (though that might not make any difference)... how about using the -L switch?

-L /opt/msp430-elf-6.2.1.16/msp430-elf/lib/430 -T msp430g2231.ld

Good luck,

Benjamin.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

David W. Schultz
In reply to this post by Bob von Knobloch-2
On 03/06/2017 09:42 AM, Bob von Knobloch wrote:
> Now the linker doesn't want to play with me - it cannot find the
> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h"
> in the same directory.

I include -Wl,-L$(SUPPORT_FILE_DIRECTORY) in the flags for gcc when
linking.

SUPPORT_FILE_DIRECTORY having previously been set to /usr/ti/gcc/include


--
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Bob von Knobloch-2
In reply to this post by Ben Green
On 06/03/17 16:58, Ben Green wrote:

>>From my understanding the .h files and the .ld files are not supposed to be in the same directory. When in installed msp430-gcc-support-files-1.198.zip I did this:

Curious, as the TI installer places them there (under
/opt/msp430-gcc/include)

> cp *.ld /opt/msp430-elf-6.2.1.16/msp430-elf/lib/430/
> cp *.h /opt/msp430-elf-6.2.1.16/msp430-elf/include/

Makes sense - I'll try that.

> Now that does seem strange, I would have expected that to work, did you make sure you were passing the argument to the linker and not GCC (though that might not make any difference)... how about using the -L switch?
>
> -L /opt/msp430-elf-6.2.1.16/msp430-elf/lib/430 -T msp430g2231.ld

Yes, tried that too.

> Benjamin.

Yes, splitting the two worked, (I wonder why they installed into the
same place?) thank you Ben.


 From David Schultz,

 > I include -Wl,-L$(SUPPORT_FILE_DIRECTORY) in the flags for gcc when
 > linking.

I had tried this, but no joy.

Now I have to find out where the vectors have gone - they are missing
from the .hex file. Maybe a different name from the old mspgcc?

Cheers,

Bob

--
The Sun is out, the sky is blue, it's time to drive the MR2.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

DJ Delorie
In reply to this post by Bob von Knobloch-2

Bob von Knobloch <[hidden email]> writes:
> Now the linker doesn't want to play with me - it cannot find the
> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h"
> in the same directory.

Add "-v" to your gcc line, it will show you more info on where it's
searching for things.  Note that the linker and the preprocessor use
different search paths; the path to the linker script may come from gcc
(via -L or an absolute path) or from the linker's built-in path.

You can also use "strace -f -o /tmp/foo gcc . . ." to capture all the
places it searches for files (grep for msp430g2231 in that file), which
might help.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

David W. Schultz
In reply to this post by Bob von Knobloch-2
On 03/06/2017 10:25 AM, Bob von Knobloch wrote:
> Now I have to find out where the vectors have gone - they are missing
> from the .hex file. Maybe a different name from the old mspgcc?
>

TI moved a lot of things into the linker scripts a while back. Each
vector now gets its own section and as near as I can tell, these will
not appear in the output unless you have an actual ISR defined.

I have three interrupt service routines in the program I am using as an
example and the hex file includes this:

:02FFE6001259AE
:02FFEA00A883EA
:02FFF400EE55C8
:02FFFE006A5245

I count three interrupt vectors plus reset.

--
David W. Schultz
http://home.earthlink.net/~david.schultz
"Life without stock is barely worth living..." - Anthony Bourdain

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Bob von Knobloch-2
In reply to this post by DJ Delorie
On 06/03/17 17:52, DJ Delorie wrote:

>
> Bob von Knobloch <[hidden email]> writes:
>> Now the linker doesn't want to play with me - it cannot find the
>> "msp430g2231.ld" link file. Curious because the compiler fids "msp430.h"
>> in the same directory.
>
> Add "-v" to your gcc line, it will show you more info on where it's
> searching for things.  Note that the linker and the preprocessor use
> different search paths; the path to the linker script may come from gcc
> (via -L or an absolute path) or from the linker's built-in path.
>
> You can also use "strace -f -o /tmp/foo gcc . . ." to capture all the
> places it searches for files (grep for msp430g2231 in that file), which
> might help.
>
Thanks DJ,
the -v flag is very useful. I solved this problem by moving the -ld scripts.
Now I must find the vectors which do not appear in my hex file.

Regards,
Bob

--
The Sun is out, the sky is blue, it's time to drive the MR2.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TI compiler

Bob von Knobloch-2
In reply to this post by David W. Schultz
On 06/03/17 18:09, David W. Schultz wrote:

> On 03/06/2017 10:25 AM, Bob von Knobloch wrote:
>> Now I have to find out where the vectors have gone - they are missing
>> from the .hex file. Maybe a different name from the old mspgcc?
>>
>
> TI moved a lot of things into the linker scripts a while back. Each
> vector now gets its own section and as near as I can tell, these will
> not appear in the output unless you have an actual ISR defined.
>
> I have three interrupt service routines in the program I am using as an
> example and the hex file includes this:
>
> :02FFE6001259AE
> :02FFEA00A883EA
> :02FFF400EE55C8
> :02FFFE006A5245
>
> I count three interrupt vectors plus reset.
>

Hi David,
How have you extracted these from the .elf file?
I have no vectors, not even reset (and there are 2 ISRs defined):
Regards,
Bob

--
The Sun is out, the sky is blue, it's time to drive the MR2.

------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
12
Loading...