Re: Specifics on declaring sections in C code

Re: Specifics on declaring sections in C code

[Michael Sokolov]

Christopher Bahns <chris@bahns.com> wrote:

> 1. In my C source code, how do I direct specific types of information to
> certain sections? E.g. what if I want my code and initialized data to go
> into one section, uninitialized data to go into another section, and
> string literals to go into another? Of course, I want to specify the
> sections, since I want to override the default ".bss", ".text", ".data",
> etc.

Use section attributes. See "Function Attributes" and "Variable Attributes" in
"Using and Porting GCC".

> 2. Is there a return type from GNU's __asm__()? It appears that MRI's
> asm() can be used in the following way:
>
>     pTblRam = asm(void*, " move.l #.STARTOF.(UITBL_RAM),D0 ");
>
> Does GNU's __asm__() allow you to provide two arguments and/or use a
> return value? It would appear that MRI's asm() returns the value of the
> D0 register, with the type that is given as the first parameter ("void*"
> in this case). Again, MRI people please correct me if I'm wrong here.
> Anyone know how I should convert this line of MRI-compatible source code
> to GNU?
>
> Is GNU's __asm__ directive documented thoroughly somewhere?

See "Extended Asm" in "Using and Porting GCC".

--
Michael Sokolov		Harhan Engineering Laboratory
Public Service Agent	International Free Computing Task Force
			International Engineering and Science Task Force
			615 N GOOD LATIMER EXPY STE #4
			DALLAS TX 75204-5852 USA

Phone: +1-214-824-7693 (Harhan Eng Lab office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon)

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Specifics on declaring sections in C code

[Christopher Bahns]

Hello,

I am converting some code from MRI to GNU (m68k target) and have run
into a couple of issues.


1. In my C source code, how do I direct specific types of information to
certain sections? E.g. what if I want my code and initialized data to go
into one section, uninitialized data to go into another section, and
string literals to go into another? Of course, I want to specify the
sections, since I want to override the default ".bss", ".text", ".data",
etc.

Here is a piece of code that works with MRI:
____________________________________________________________
#include "idents.h"

#pragma option -NCUITBL_ROM
#pragma option -NZUITBL_RAM

DMFL_Ram_t DMFL_Ram[NUM_UI_VAR_LOC];

const DMFL_Rom_t DMFL_Rom [] =
{
/* * index, name * initvalue */
   <cut>
};
____________________________________________________________

If someone that knows about the "-NC" and "-NZ" MRI options I'd
appreciate letting me know what they do (I don't have documentation). I
*think* they say to put code (and possible initialized data?) in the
section "UITBL_ROM" and to put uninitialized data in the section
"UITBL_RAM". I did verify in the map file that "DMFL_Ram" was put into
"UITBL_RAM" and that "DMFL_Rom" was put into ROM. I assume the MRI
compiler made the distinction based on whether or not the variable is
initialized.

So, how can I do something similar with GNU? What I came up with is
inconvenient:
____________________________________________________________
#include "idents.h"

__asm__( ".section UITBL_RAM,\"d\"" );

DMFL_Ram_t DMFL_Ram[NUM_UI_VAR_LOC];

__asm__( ".section UITBL_ROM,\"x\"" );

const DMFL_Rom_t DMFL_Rom [] =
{
/* * index, name * initvalue */
   <cut>
};
____________________________________________________________

This can get very messy in a larger file that has initialized data,
unititialized data, and source code mixed up a bit.. Also, it's much
more prone to error if I add stuff in the future to make sure that it is
added after the proper directive. With MRI's options, I can just put all
relevant options at the top of the file and then forget about it. No
matter where I add various kinds of information they will always get
placed in the proper section (assuming I've interpreted the meanings of
the options accurately).

Does anyone know of a cleaner way to do this with GNU/GCC/AS? I'd be
interested in assembler directives, C directives, command line options,
whatever.


2. Is there a return type from GNU's __asm__()? It appears that MRI's
asm() can be used in the following way:

    pTblRam = asm(void*, " move.l #.STARTOF.(UITBL_RAM),D0 ");

Does GNU's __asm__() allow you to provide two arguments and/or use a
return value? It would appear that MRI's asm() returns the value of the
D0 register, with the type that is given as the first parameter ("void*"
in this case). Again, MRI people please correct me if I'm wrong here.
Anyone know how I should convert this line of MRI-compatible source code
to GNU?

Is GNU's __asm__ directive documented thoroughly somewhere?


I'd appreciate any help! Naturally I've already looked through the GNU
gcc, ld, and as documents, as well as used 'man' and 'info' (which was
mostly the same as what was in the documents).

Chris