Re: Accessing section attributes from assembly (or C)

Re: Accessing section attributes from assembly (or C)

[Joseph Taylor]

[-- Attachment #1: Type: text/plain, Size: 2858 bytes --]

Beware.  In porting my MRI code, I found the MRI Compatibility Mode in the
linker to be somewhat of a misnomer and also misleading.  Sure, ld supports a
few MRI commands, but there are too many unsupported (or ignored) commands.  Any
significant MRI project will encounter these unsupported commands, and
work-arounds don't exist.  In my opinion, there is no MRI Compatibility Mode.

This incompatibility was probably better for me in the long run, though, because
it forced me to learn ld's native command language.  Now I use the native
command language exclusively (and happily).    :-)

Joe

And don't tell me there isn't one bit of difference between null and space,
because that's exactly how much difference there is.  :-)
   --- Larry Wall






Ola Liljedahl <olli@enea.se> on 07/05/2000 09:16:13 AM

To:   Michael Sokolov <msokolov@ivan.harhan.org>
cc:   chris@bahns.com, crossgcc@sourceware.cygnus.com (bcc: Joseph
      Taylor/Inter-Tel)

Subject:  Re: Accessing section attributes from assembly (or C)



MRI == Microtec
A cross compiler tool chain for embedded systems popular enough for
gcc (or is it the binutils assembler) to actually have an mri
compatibility mode. But probably the compatibility does not stretch
long enough to handle such weird relocations.
--
     Ola Liljedahl

Michael Sokolov wrote:
>
> Christopher Bahns <chris@bahns.com> wrote:
>
> > "            DC.L  (tables1_size + tables2_size)\n"
>
> Sorry, the UNIX model of an object module, which the GNU toolchain follows
just
> like any other UNIX toolchain, does not allow referencing things like the sum
> of two external symbols.
>
> > It seems that MRI can do this, but GNU
> > (as far as I know) cannot.
>
> It isn't GNU that invented this limitation, it's the UNIX way of doing things,
> of which GNU is just one implementation.
>
> As you are making comparisons with something called "MRI", you may want to
> explain what it is you are making comparisons with. To me MRI doesn't mean
> anything other than Magnetic Resonance Imaging. It seems like you are talking
> about some other compiler/assembler/linker toolchain. What sort of toolchain
is
> it? Is it used by some proprietary version of UNIX, or is it a specialized
> embedded cross-toolchain, or what?
>
> --
> 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

[-- Attachment #2: olli.vcf --]
[-- Type: text/plain, Size: 193 bytes --]

begin:vcard 
n:Liljedahl;Ola
x-mozilla-html:FALSE
org:Enea OSE Systems;R & D
adr:;;;;;;
version:2.1
email;internet:olli@enea.se
title:Technical Manager
fn:Ola Liljedahl
end:vcard

Re: Accessing section attributes from assembly (or C)

[Michael Sokolov]

Christopher Bahns <chris@bahns.com> wrote:

> [...] whereas GNU is said to be very good and costs nothing.

Yes, the Cygnus/GNU software development toolchain is by far the best in the
world! (I say Cygnus/GNU because of newlib and other pieces that aren't GNU,
and because I'm interested in it strictly as a stand-alone self-sufficient
toolchain for embedded and other software development, not as part of the GNU
project to replace UNIX and its native components. I can't promote the latter,
as I'm a UNIX maintainer.)

> Plus it has very good and
> responsive support on this mailing list, for free as well.

Yes! I try to contribute to it where I can...

--
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

Re: Accessing section attributes from assembly (or C)

[Christopher Bahns]

Sorry bout that. MRI = Microtec Research (International?). They make an m68k
compiler for Windows. Perhaps they support other processors, but I don't know much
else. My purpose is to convert all project code from MRI to GNU because MRI costs
like $2500 for each developer (similar to other commercial compilers I think),
whereas GNU is said to be very good and costs nothing. Plus it has very good and
responsive support on this mailing list, for free as well.

Michael Sokolov wrote:

> Christopher Bahns <chris@bahns.com> wrote:
>
> > "            DC.L  (tables1_size + tables2_size)\n"
>
> Sorry, the UNIX model of an object module, which the GNU toolchain follows just
> like any other UNIX toolchain, does not allow referencing things like the sum
> of two external symbols.
>
> > It seems that MRI can do this, but GNU
> > (as far as I know) cannot.
>
> It isn't GNU that invented this limitation, it's the UNIX way of doing things,
> of which GNU is just one implementation.
>
> As you are making comparisons with something called "MRI", you may want to
> explain what it is you are making comparisons with. To me MRI doesn't mean
> anything other than Magnetic Resonance Imaging. It seems like you are talking
> about some other compiler/assembler/linker toolchain. What sort of toolchain is
> it? Is it used by some proprietary version of UNIX, or is it a specialized
> embedded cross-toolchain, or what?
>
> --
> 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

Re: Accessing section attributes from assembly (or C)

[Ola Liljedahl]

MRI == Microtec
A cross compiler tool chain for embedded systems popular enough for
gcc (or is it the binutils assembler) to actually have an mri
compatibility mode. But probably the compatibility does not stretch
long enough to handle such weird relocations.
--
	Ola Liljedahl

Michael Sokolov wrote:
> 
> Christopher Bahns <chris@bahns.com> wrote:
> 
> > "            DC.L  (tables1_size + tables2_size)\n"
> 
> Sorry, the UNIX model of an object module, which the GNU toolchain follows just
> like any other UNIX toolchain, does not allow referencing things like the sum
> of two external symbols.
> 
> > It seems that MRI can do this, but GNU
> > (as far as I know) cannot.
> 
> It isn't GNU that invented this limitation, it's the UNIX way of doing things,
> of which GNU is just one implementation.
> 
> As you are making comparisons with something called "MRI", you may want to
> explain what it is you are making comparisons with. To me MRI doesn't mean
> anything other than Magnetic Resonance Imaging. It seems like you are talking
> about some other compiler/assembler/linker toolchain. What sort of toolchain is
> it? Is it used by some proprietary version of UNIX, or is it a specialized
> embedded cross-toolchain, or what?
> 
> --
> 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
begin:vcard 
n:Liljedahl;Ola
x-mozilla-html:FALSE
org:Enea OSE Systems;R & D
adr:;;;;;;
version:2.1
email;internet:olli@enea.se
title:Technical Manager
fn:Ola Liljedahl
end:vcard

Re: Accessing section attributes from assembly (or C)

[Michael Sokolov]

Christopher Bahns <chris@bahns.com> wrote:

> "            DC.L  (tables1_size + tables2_size)\n"

Sorry, the UNIX model of an object module, which the GNU toolchain follows just
like any other UNIX toolchain, does not allow referencing things like the sum
of two external symbols.

> It seems that MRI can do this, but GNU
> (as far as I know) cannot.

It isn't GNU that invented this limitation, it's the UNIX way of doing things,
of which GNU is just one implementation.

As you are making comparisons with something called "MRI", you may want to
explain what it is you are making comparisons with. To me MRI doesn't mean
anything other than Magnetic Resonance Imaging. It seems like you are talking
about some other compiler/assembler/linker toolchain. What sort of toolchain is
it? Is it used by some proprietary version of UNIX, or is it a specialized
embedded cross-toolchain, or what?

--
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

Re: Accessing section attributes from assembly (or C)

[Christopher Bahns]

I'm sorry, it would appear that the simple example I showed you *does* work, which
is good. However, my initial error happened when I tried to use the linker-script
symbols in an expression (I oversimplified my problem in the last message).

Try this for the linker script excerpt:
__________________________________________________________________
  tables : {
        tables1_start = .;
        *(tables1)
        tables1_end = .;

        tables2_start = .;
        *(tables2)
        tables2_end = .;
  } > rom

  tables1_size = tables1_end - tables1_start;
  tables2_size = tables2_end - tables2_start;
__________________________________________________________________


Now let's say we want to put the sum of the two sizes in our assembly code:
__________________________________________________________________
__asm__(
"   .extern tables1_size\n"
"   .extern tables2_size\n"
"DATA_Table:\n"
"            DC.B  0x01\n"                  /* UBYTE table format version */
"            DC.B  0x00\n"                  /* UBYTE unused_a for alignment */
"            DC.L  (tables1_size + tables2_size)\n"
)
__________________________________________________________________


With this the assembler gives me:
"Error: undefined symbol __data_end in operation"
"Error: undefined symbol __data_start in operation"

I know what I can do: define yet another variable in the linker script:
        "tables_size = tables2_end - tables1_start"
or something like this. I really don't like this because there are quite a few
references throughout my C/assembly code referring to section starting addresses
and sizes. It seems a bit kludgy to have to make up a new variable in the linker
script for every calculated value that is required in the source code. I'd like my
linker scripts just to provide the necessary information for the link, and not
have too many cross-dependencies between my source code and linker scripts. The
linker script should not have to change each time I want to get information in a
slightly different way from source code. It seems that MRI can do this, but GNU
(as far as I know) cannot.

The following code works with MRI:
__________________________________________________________________
#pragma asm
   XDEF   _DATA_Table
_DATA_Table:
            DC.B  $01                  /* UBYTE table format version */
            DC.B  $00                  /* UBYTE unused_a for alignment */
            DC.L  .SIZEOF.(tables1)+.SIZEOF.(tables2)
#pragma endasm
__________________________________________________________________

In this case I don't have to define any additional symbols in the linker script.
It is very easy to put section information directly into the source code, and
combine them in an expression. Does anyone know a way to do something similar with
GNU? If you can think of an easier to accomplish what I'm trying to do, please let
me know.

Sorry for the functional example in the last message.
Chris

Christopher Bahns wrote:

> How can I access information about a section from within my C or
> assembly code? Specifically, I need to know the starting address and
> size (or ending address) of a section. Now, I already know how to do
> this as a C-language variable, but I think I need access to these values
> as literals. Hold on a sec and I'll show why...
>
> Here is an excerpt from my linker script:
> __________________________________________________________________
>   .my_tables : {
>         __tables_start = .;
>         *(.my_tables)
>         __tables_end = .;
>         __tables_size = __tables_end - __tables_start;
>   } > rom
> __________________________________________________________________
>
> And here is some assembly code (inside a C file):
> __________________________________________________________________
> __asm__(
> "   .extern __tables_size\n"
> "DATA_Table:\n"
> "            DC.B  0x01\n"                  /* UBYTE table format
> version */
> "            DC.B  0x00\n"                  /* UBYTE unused_a for
> alignment */
> "            DC.L  __tables_size\n"
> )
> __________________________________________________________________
>
> Note that the linker would have to put the final (literal) value of
> "__tables_size" directly at this location at link time. I can't really
> use a variable to refer to "__tables_size" and copy the value to this
> location at run time (at least not easily). The above code generates an
> error in the assembler: "Error: undefined symbol __tables_size in
> operation".
>
> It is possible to do this with MRI (I am converting from MRI to GNU), so
> I really hope GNU has an easy way to do this as well. I've looked
> through some of the documentation but not thoroughly. If you can point
> me to the right part of the documentation please do. I *really* don't
> want to use MRI-compatibility mode. I've already gotten most of it
> converted to GNU and would like to move totally from the old syntax. If
> GNU simply cannot do some of the nice things that MRI can do, then I'll
> be sorely disappointed.
>
> Here is the corresponding MRI-compatible assembly code:
> __________________________________________________________________
> #pragma asm
>    XDEF   _DATA_Table
> _DATA_Table:
>             DC.B  $01                  /* UBYTE table format version */
>             DC.B  $00                  /* UBYTE unused_a for alignment
> */
>             DC.L  .SIZEOF.(.my_tables)
> #pragma endasm
> __________________________________________________________________
>
> As you can see with MRI it is easy. I can have the linker just stick the
> size of the ".my_tables" section directly at the desired location, using
> the ".SIZEOF." directive. MRI also has a ".STARTOF." directive for
> obtaining the start address of a section.
>
> Can anyone help? (Thanks to those that helped me with other stuff...
> almost there now.)
> Chris
>
>   ------------------------------------------------------------------------
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Accessing section attributes from assembly (or C)

[Christopher Bahns]

How can I access information about a section from within my C or
assembly code? Specifically, I need to know the starting address and
size (or ending address) of a section. Now, I already know how to do
this as a C-language variable, but I think I need access to these values
as literals. Hold on a sec and I'll show why...

Here is an excerpt from my linker script:
__________________________________________________________________
  .my_tables : {
        __tables_start = .;
        *(.my_tables)
        __tables_end = .;
        __tables_size = __tables_end - __tables_start;
  } > rom
__________________________________________________________________

And here is some assembly code (inside a C file):
__________________________________________________________________
__asm__(
"   .extern __tables_size\n"
"DATA_Table:\n"
"            DC.B  0x01\n"                  /* UBYTE table format
version */
"            DC.B  0x00\n"                  /* UBYTE unused_a for
alignment */
"            DC.L  __tables_size\n"
)
__________________________________________________________________

Note that the linker would have to put the final (literal) value of
"__tables_size" directly at this location at link time. I can't really
use a variable to refer to "__tables_size" and copy the value to this
location at run time (at least not easily). The above code generates an
error in the assembler: "Error: undefined symbol __tables_size in
operation".

It is possible to do this with MRI (I am converting from MRI to GNU), so
I really hope GNU has an easy way to do this as well. I've looked
through some of the documentation but not thoroughly. If you can point
me to the right part of the documentation please do. I *really* don't
want to use MRI-compatibility mode. I've already gotten most of it
converted to GNU and would like to move totally from the old syntax. If
GNU simply cannot do some of the nice things that MRI can do, then I'll
be sorely disappointed.

Here is the corresponding MRI-compatible assembly code:
__________________________________________________________________
#pragma asm
   XDEF   _DATA_Table
_DATA_Table:
            DC.B  $01                  /* UBYTE table format version */
            DC.B  $00                  /* UBYTE unused_a for alignment
*/
            DC.L  .SIZEOF.(.my_tables)
#pragma endasm
__________________________________________________________________

As you can see with MRI it is easy. I can have the linker just stick the
size of the ".my_tables" section directly at the desired location, using
the ".SIZEOF." directive. MRI also has a ".STARTOF." directive for
obtaining the start address of a section.


Can anyone help? (Thanks to those that helped me with other stuff...
almost there now.)
Chris