#354 named code sections

open
nobody
5
2012-04-01
2012-04-01
achdawai
No

hi

for the moment all PIC16 code sections are named according to the file and function, and #pragma codeseg has no effect.

The only way to change the code's position is using a command line option that defines the beginning of the code *segment*.

For a boot/os/app software design, a way to assign a specific section to any function is desired.

gplink already supports that.

the only required bit is a working #pragma codeseg <section> that will define the current section name instead of a S_file__func template
Is this naming required for anything?

Is this request doable?

thanks for any info.

Discussion

1 2 > >> (Page 1 of 2)
  • achdawai
    achdawai
    2012-04-02

    I can get the needed effect for RAM variables, e.g.

    #pragma udata boot timer_msw
    ushort timer_msw;

    generates:
    boot udata
    _timer_msw res 2

    I will try to compile something similar for code sections.
    #pragma code <section> <function>

    but for the moment, pragma code works like a ".org" :
    #pragma code <function> <address>

    that's not very coherent.

    #pragma codeseg seems to have another meaning.

     
  • achdawai
    achdawai
    2012-04-02

    OK, I tried to get a working sdcc source tree under mingw but I can't get it to compile! I have downloaded boost (96MB!) , I understand I don't have to compile anything to use graphs, I have it exported in CXXFLAGS and CPPFLAGS, but it does not work, I get various compilations errors.

    So let it be. I'll do it in linux.

    At the moment, I:

    -managed to understand how the asm file is generated via pcode elements. I added a "char *section" field in the pcode structure for functions, added a parameter to pic16_newpCodeFunction and got it compiled. For the moment all calls use NULL here so pcode.c generates the normal function prolog. If this field is not null, a simpler prolog is generated using the passed section name instead of S_%s__%s.

    -managed to add a #pragma text [sym] [section] that is, for the moment managed the exact same way as #pragma udata.

    What I need to understand now is how #pragma data is propagated to pcodes.

    Any help is welcome, especially from the main developers.

     
  • achdawai
    achdawai
    2012-04-03

    a better idea was implemented, see attached patch against svn

     
  • achdawai
    achdawai
    2012-04-03

    I just implemented a simpler idea, see attached patch against svn 7529.

    now, from sdcc side, it works.

    However I'm getting into gpasm issues, see the attached test case, compiled with:
    sdcc -c --use-non-free -mpic16 -p18F2620 bootmain.c -o bootmain.o

    main.c:444 placing udata symbol _var at section boot (0x924fc18)
    main.c:444 placing text symbol _start at section boot (0x9250c60)
    main.c:444 placing text symbol _appmain at section app (0x925cff8)
    main.c:444 placing text symbol _appsuite at section app (0x925cff8)
    for function _appsuite a section was found : app
    section app found in the list of text sections
    for function _appmain a section was found : app
    section app found in the list of text sections
    for function _start a section was found : boot
    section boot found in the list of text sections
    bootmain.asm:223:Error[154] Each object file section must be contiguous.
    bootmain.asm:223:Error[116] Value of symbol "_appmain" differs on second pass
    pass 1=0, pass 2=16
    bootmain.asm:247:Error[154] Each object file section must be contiguous.
    bootmain.asm:247:Error[116] Value of symbol "_start" differs on second pass
    pass 1=0, pass 2=16

    Please see the attached bootmain.lst and bootmain.asm .

    In the asm file, everything is OK.

    However gpasm does not like to see two functions in the same section!
    The first pass assembles each function at address zero, however the second pass concatenates the similar sections and signals an address change!

    Any ideas?

     
  • achdawai
    achdawai
    2012-04-03

    preliminary patch to support named code sections

     
  • achdawai
    achdawai
    2012-04-03

    test source file

     
    Attachments
  • achdawai
    achdawai
    2012-04-03

    generated file

     
    Attachments
  • achdawai
    achdawai
    2012-04-03

    asm listing file, generated by gpasm

     
    Attachments
  • achdawai
    achdawai
    2012-04-03

    I'm now bumping into gputils feature request 951216

    No news since 2007-11-24 08:58:21 PST !

    I can't believe it!

    sections names must be unique within each file, just because old mplab documentation wrote that.
    There is absolutely no requirement on that, but nobody wants to "break compatibility".

    I will investigate that.

     
  • Borut Ražem
    Borut Ražem
    2012-05-02

    > sections names must be unique within each file, just because old mplab documentation wrote that.

    This should not be a problem for sdcc: it should just collect all functions / variables belonging to the same section and group them together in the generated asm so that the section is defined only once.

    Borut

     
1 2 > >> (Page 1 of 2)