• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 53 subscribers
  • Views 291 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Debugger symbol information from ASM file

Helge Kruse
Intellectual 435 points


I have an application where the MSP430F26xx RAM is more or less completely consumed. The largest data used in the application are value arrays:

typedef struct _Foo { int a, b; } Foo;
typedef struct _Bar { int x, y, z; } Bar;

extern Foo s_FooData[300];
extern Bar s_BarData[200];

I need to write a tester for that application that uses additional RAM. The data in s_FooData and s_BarData is never used at the same time during this test. So it would be useful that both variable share a common space in the physical RAM. Is it possible to direct the linker to place both variables at the same address? Of course this is not sensible for the application although it would help with the test. I found a way to proceed in the direction. I added an assembler file to the tester that defines the required symbols and reserves space:

.def s_FooData, s_BarData
.bss s_FooData, 0
.bss s_BarData, 900
.end

But when I load this program in the debugger I have lost the symbol information. Although the C code accesses the typed variable s_FooData correctly it is shown as type of void*. When I try to add some DWARF instructions from the C assembler output I get the error message:

[W0003] This file contains DWARF directives that can only be used in unmodified assembly files generated by the compiler; ignoring all DWARF directives.

How can I add symbol information for the debugger?

  • 0
    TI__Guru**** 251300 points

    I recommend you set up all the data in C.  In the linker command file, overlap the arrays with the UNION directive.

    Your C code looks like ...

    typedef struct foo { int a, b; } foo;
    typedef struct bar { int x, y, z; } bar;

    #pragma DATA_SECTION(foo_data, "for_foo");
    foo foo_data[300];
    #pragma DATA_SECTION(bar_data, "for_bar");
    bar bar_data[300];

    And your link command file, in the SECTIONS directive, looks like ...

    UNION
    {
        for_foo
        for_bar
    } > SHRAM

    CCS does not notice that these two arrays are at the same address.  If, during some part of execution where foo_data is being operated on, you look at the contents of bar_data, it won't make any sense.  Once you know to expect that, it isn't difficult to manage.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 435 points

    This works. Great.

    It's not documented MSP430 Optimizing C/C++ Compiler v3.3  User's Guide (SLAU132E.pdf) that I was using. But there is a statement that you find a complete description in the MSP430 Assembly Language Tools User's Guide.

    This makes all experiments like shown above unnecessary. 

    Thanks
    Helge 

  • 0 in reply to Helge Kruse
    TI__Guru**** 251300 points

    Complete documentation for the linker is contained in the MSP430 Assembly Language Tools User's Guide.

    Thanks and regards,

    -George