Linker Sections and OBJDUMP

public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed

* Linker Sections and OBJDUMP
@ 2000-01-06 16:06 Rudy Folden
  2000-01-07  6:07 ` Eric DeVolder
  2000-04-01  0:00 ` Rudy Folden
  0 siblings, 2 replies; 4+ messages in thread
From: Rudy Folden @ 2000-01-06 16:06 UTC (permalink / raw)
  To: help-gcc

Hi,

I am converting a proprietary operating system for the PowerPC from the Diab
and Metaware tools sets to GNU and have identified a new section called
".vect" which contains instructions and vectors and which must be loaded at
a specific address.  This was the process used under Diab and Metaware.

I use the following directive in the appropriate assembly files:

    .section .vect

and it appeared to work since the map shows the section loaded to the
correct address.

However, since I am converting existing startup code from the Diab tools to
the GNU tools,  I wanted to insure that the object generated was correct.
So, I tried disassembling the objects that contain the .vect sections using
the "objdump -D" option but I do not get a disassembly...it is blank.

Also, when I dump the object using "objdump -h" it shows attributes for the
.text and .data sections such as LOAD, READONLY, CODE or DATA, but the new
.vect section does NOT show up as CODE. This leads me to believe that the
object modules may not be relocatable and externals defined therein may not
be resolved correctly.

The following is the output of the "objdump -h" command:

VBD60\PP6ra.o:     file format elf32-powerpc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         001c2dc8  ff800000  ff800000  00040000  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         000294b0  10000000  10000000  00010000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .vxworks      00000308  100e0000  100e0000  00202dc8  2**0
                  CONTENTS
  3 .vect         00002250  fff00000  fff00000  00203100  2**8
                  CONTENTS, READONLY
  4 .comment      00004de0  100294b0  100294b0  00205350  2**0
                  CONTENTS, READONLY
  5 .stab         00004788  1002e290  1002e290  0020a130  2**2
                  CONTENTS, READONLY, DEBUGGING
  6 .debug        00045c90  1003748c  1003748c  0020e8b8  2**2
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_srcinfo0000012c  1007d11c  1007d11c  00254548  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_aranges000001bc  1007d248  1007d248  00254674  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_pubnames000008cb  1007d404  1007d404  00254830  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_sfnames00000255  1007dccf  1007dccf  002550fb  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .line         00002d6a  1007df24  1007df24  00255350  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .stabstr      00004a73  10032a18  10032a18  002580ba  2**0
                  CONTENTS, READONLY, DEBUGGING

Does anyone have insight into this situation? I would really like to
disassemble the objects to insure that the code is being generated
correctly.
I am hoping that there might be an option on the .section directive that
would cause it to be treated as an "executable" section with a unique name
(as with Diab), but there is not one documented.

Thanks,
Rudy L. Folden

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Linker Sections and OBJDUMP
  2000-01-06 16:06 Linker Sections and OBJDUMP Rudy Folden
@ 2000-01-07  6:07 ` Eric DeVolder
  2000-04-01  0:00   ` Eric DeVolder
  2000-04-01  0:00 ` Rudy Folden
  1 sibling, 1 reply; 4+ messages in thread
From: Eric DeVolder @ 2000-01-07  6:07 UTC (permalink / raw)
  To: Rudy Folden; +Cc: help-gcc

I'm no objdump expert, buy my limited experience shows that objdump disassembles
sections marked as code, normally your .text. Also, with GAS, you can specify
attributes to a section with the .section pseudo op.

Have a look at 'info gas' (or 'info gas' depending on your system), and you'll
see that you can provide section attributes for bss, noload, writable, data,
read-only, and ... executable! Here is the first page of the info page...

File: as.info,  Node: Section,  Next: Set,  Prev: Scl,  Up: Pseudo Ops

`.section NAME'
===============

   Use the `.section' directive to assemble the following code into a
section named NAME.

   This directive is only supported for targets that actually support
arbitrarily named sections; on `a.out' targets, for example, it is not
accepted, even with a standard `a.out' section name.

   For COFF targets, the `.section' directive is used in one of the
following ways:
     .section NAME[, "FLAGS"]
     .section NAME[, SUBSEGMENT]

   If the optional argument is quoted, it is taken as flags to use for
the section.  Each flag is a single character.  The following flags are
recognized:
`b'
     bss section (uninitialized data)

`n'
     section is not loaded

`w'
     writable section

`d'
     data section

`r'
     read-only section

`x'
     executable section

   If no flags are specified, the default flags depend upon the section
name.  If the section name is not recognized, the default will be for
the section to be loaded and writable.

   If the optional argument to the `.section' directive is not quoted,
it is taken as a subsegment number (*note Sub-Sections::.).

   For ELF targets, the `.section' directive is used like this:
     .section NAME[, "FLAGS"[, @TYPE]]
   The optional FLAGS argument is a quoted string which may contain any
combintion of the following characters:
`a'
     section is allocatable

`w'
     section is writable

`x'
     section is executable



Rudy Folden wrote:

> Hi,
>
> I am converting a proprietary operating system for the PowerPC from the Diab
> and Metaware tools sets to GNU and have identified a new section called
> ".vect" which contains instructions and vectors and which must be loaded at
> a specific address.  This was the process used under Diab and Metaware.
>
> I use the following directive in the appropriate assembly files:
>
>     .section .vect
>
> and it appeared to work since the map shows the section loaded to the
> correct address.
>
> However, since I am converting existing startup code from the Diab tools to
> the GNU tools,  I wanted to insure that the object generated was correct.
> So, I tried disassembling the objects that contain the .vect sections using
> the "objdump -D" option but I do not get a disassembly...it is blank.
>
> Also, when I dump the object using "objdump -h" it shows attributes for the
> .text and .data sections such as LOAD, READONLY, CODE or DATA, but the new
> .vect section does NOT show up as CODE. This leads me to believe that the
> object modules may not be relocatable and externals defined therein may not
> be resolved correctly.
>
> The following is the output of the "objdump -h" command:
>
> VBD60\PP6ra.o:     file format elf32-powerpc
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         001c2dc8  ff800000  ff800000  00040000  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .data         000294b0  10000000  10000000  00010000  2**4
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .vxworks      00000308  100e0000  100e0000  00202dc8  2**0
>                   CONTENTS
>   3 .vect         00002250  fff00000  fff00000  00203100  2**8
>                   CONTENTS, READONLY
>   4 .comment      00004de0  100294b0  100294b0  00205350  2**0
>                   CONTENTS, READONLY
>   5 .stab         00004788  1002e290  1002e290  0020a130  2**2
>                   CONTENTS, READONLY, DEBUGGING
>   6 .debug        00045c90  1003748c  1003748c  0020e8b8  2**2
>                   CONTENTS, READONLY, DEBUGGING
>   7 .debug_srcinfo0000012c  1007d11c  1007d11c  00254548  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   8 .debug_aranges000001bc  1007d248  1007d248  00254674  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   9 .debug_pubnames000008cb  1007d404  1007d404  00254830  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  10 .debug_sfnames00000255  1007dccf  1007dccf  002550fb  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  11 .line         00002d6a  1007df24  1007df24  00255350  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  12 .stabstr      00004a73  10032a18  10032a18  002580ba  2**0
>                   CONTENTS, READONLY, DEBUGGING
>
> Does anyone have insight into this situation? I would really like to
> disassemble the objects to insure that the code is being generated
> correctly.
> I am hoping that there might be an option on the .section directive that
> would cause it to be treated as an "executable" section with a unique name
> (as with Diab), but there is not one documented.
>
> Thanks,
> Rudy L. Folden

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Linker Sections and OBJDUMP
  2000-01-07  6:07 ` Eric DeVolder
@ 2000-04-01  0:00   ` Eric DeVolder
  0 siblings, 0 replies; 4+ messages in thread
From: Eric DeVolder @ 2000-04-01  0:00 UTC (permalink / raw)
  To: Rudy Folden; +Cc: help-gcc

I'm no objdump expert, buy my limited experience shows that objdump disassembles
sections marked as code, normally your .text. Also, with GAS, you can specify
attributes to a section with the .section pseudo op.

Have a look at 'info gas' (or 'info gas' depending on your system), and you'll
see that you can provide section attributes for bss, noload, writable, data,
read-only, and ... executable! Here is the first page of the info page...

File: as.info,  Node: Section,  Next: Set,  Prev: Scl,  Up: Pseudo Ops

`.section NAME'
===============

   Use the `.section' directive to assemble the following code into a
section named NAME.

   This directive is only supported for targets that actually support
arbitrarily named sections; on `a.out' targets, for example, it is not
accepted, even with a standard `a.out' section name.

   For COFF targets, the `.section' directive is used in one of the
following ways:
     .section NAME[, "FLAGS"]
     .section NAME[, SUBSEGMENT]

   If the optional argument is quoted, it is taken as flags to use for
the section.  Each flag is a single character.  The following flags are
recognized:
`b'
     bss section (uninitialized data)

`n'
     section is not loaded

`w'
     writable section

`d'
     data section

`r'
     read-only section

`x'
     executable section

   If no flags are specified, the default flags depend upon the section
name.  If the section name is not recognized, the default will be for
the section to be loaded and writable.

   If the optional argument to the `.section' directive is not quoted,
it is taken as a subsegment number (*note Sub-Sections::.).

   For ELF targets, the `.section' directive is used like this:
     .section NAME[, "FLAGS"[, @TYPE]]
   The optional FLAGS argument is a quoted string which may contain any
combintion of the following characters:
`a'
     section is allocatable

`w'
     section is writable

`x'
     section is executable



Rudy Folden wrote:

> Hi,
>
> I am converting a proprietary operating system for the PowerPC from the Diab
> and Metaware tools sets to GNU and have identified a new section called
> ".vect" which contains instructions and vectors and which must be loaded at
> a specific address.  This was the process used under Diab and Metaware.
>
> I use the following directive in the appropriate assembly files:
>
>     .section .vect
>
> and it appeared to work since the map shows the section loaded to the
> correct address.
>
> However, since I am converting existing startup code from the Diab tools to
> the GNU tools,  I wanted to insure that the object generated was correct.
> So, I tried disassembling the objects that contain the .vect sections using
> the "objdump -D" option but I do not get a disassembly...it is blank.
>
> Also, when I dump the object using "objdump -h" it shows attributes for the
> .text and .data sections such as LOAD, READONLY, CODE or DATA, but the new
> .vect section does NOT show up as CODE. This leads me to believe that the
> object modules may not be relocatable and externals defined therein may not
> be resolved correctly.
>
> The following is the output of the "objdump -h" command:
>
> VBD60\PP6ra.o:     file format elf32-powerpc
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         001c2dc8  ff800000  ff800000  00040000  2**4
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .data         000294b0  10000000  10000000  00010000  2**4
>                   CONTENTS, ALLOC, LOAD, DATA
>   2 .vxworks      00000308  100e0000  100e0000  00202dc8  2**0
>                   CONTENTS
>   3 .vect         00002250  fff00000  fff00000  00203100  2**8
>                   CONTENTS, READONLY
>   4 .comment      00004de0  100294b0  100294b0  00205350  2**0
>                   CONTENTS, READONLY
>   5 .stab         00004788  1002e290  1002e290  0020a130  2**2
>                   CONTENTS, READONLY, DEBUGGING
>   6 .debug        00045c90  1003748c  1003748c  0020e8b8  2**2
>                   CONTENTS, READONLY, DEBUGGING
>   7 .debug_srcinfo0000012c  1007d11c  1007d11c  00254548  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   8 .debug_aranges000001bc  1007d248  1007d248  00254674  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   9 .debug_pubnames000008cb  1007d404  1007d404  00254830  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  10 .debug_sfnames00000255  1007dccf  1007dccf  002550fb  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  11 .line         00002d6a  1007df24  1007df24  00255350  2**0
>                   CONTENTS, READONLY, DEBUGGING
>  12 .stabstr      00004a73  10032a18  10032a18  002580ba  2**0
>                   CONTENTS, READONLY, DEBUGGING
>
> Does anyone have insight into this situation? I would really like to
> disassemble the objects to insure that the code is being generated
> correctly.
> I am hoping that there might be an option on the .section directive that
> would cause it to be treated as an "executable" section with a unique name
> (as with Diab), but there is not one documented.
>
> Thanks,
> Rudy L. Folden

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Linker Sections and OBJDUMP
  2000-01-06 16:06 Linker Sections and OBJDUMP Rudy Folden
  2000-01-07  6:07 ` Eric DeVolder
@ 2000-04-01  0:00 ` Rudy Folden
  1 sibling, 0 replies; 4+ messages in thread
From: Rudy Folden @ 2000-04-01  0:00 UTC (permalink / raw)
  To: help-gcc

Hi,

I am converting a proprietary operating system for the PowerPC from the Diab
and Metaware tools sets to GNU and have identified a new section called
".vect" which contains instructions and vectors and which must be loaded at
a specific address.  This was the process used under Diab and Metaware.

I use the following directive in the appropriate assembly files:

    .section .vect

and it appeared to work since the map shows the section loaded to the
correct address.

However, since I am converting existing startup code from the Diab tools to
the GNU tools,  I wanted to insure that the object generated was correct.
So, I tried disassembling the objects that contain the .vect sections using
the "objdump -D" option but I do not get a disassembly...it is blank.

Also, when I dump the object using "objdump -h" it shows attributes for the
.text and .data sections such as LOAD, READONLY, CODE or DATA, but the new
.vect section does NOT show up as CODE. This leads me to believe that the
object modules may not be relocatable and externals defined therein may not
be resolved correctly.

The following is the output of the "objdump -h" command:

VBD60\PP6ra.o:     file format elf32-powerpc

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         001c2dc8  ff800000  ff800000  00040000  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         000294b0  10000000  10000000  00010000  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  2 .vxworks      00000308  100e0000  100e0000  00202dc8  2**0
                  CONTENTS
  3 .vect         00002250  fff00000  fff00000  00203100  2**8
                  CONTENTS, READONLY
  4 .comment      00004de0  100294b0  100294b0  00205350  2**0
                  CONTENTS, READONLY
  5 .stab         00004788  1002e290  1002e290  0020a130  2**2
                  CONTENTS, READONLY, DEBUGGING
  6 .debug        00045c90  1003748c  1003748c  0020e8b8  2**2
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_srcinfo0000012c  1007d11c  1007d11c  00254548  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_aranges000001bc  1007d248  1007d248  00254674  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_pubnames000008cb  1007d404  1007d404  00254830  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_sfnames00000255  1007dccf  1007dccf  002550fb  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .line         00002d6a  1007df24  1007df24  00255350  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .stabstr      00004a73  10032a18  10032a18  002580ba  2**0
                  CONTENTS, READONLY, DEBUGGING

Does anyone have insight into this situation? I would really like to
disassemble the objects to insure that the code is being generated
correctly.
I am hoping that there might be an option on the .section directive that
would cause it to be treated as an "executable" section with a unique name
(as with Diab), but there is not one documented.

Thanks,
Rudy L. Folden

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-04-01  0:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-06 16:06 Linker Sections and OBJDUMP Rudy Folden
2000-01-07  6:07 ` Eric DeVolder
2000-04-01  0:00   ` Eric DeVolder
2000-04-01  0:00 ` Rudy Folden

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).