From: Eric DeVolder <devolder@evsx.com>
To: Rudy Folden <rfolden@gte.net>
Cc: help-gcc@gnu.org
Subject: Re: Linker Sections and OBJDUMP
Date: Fri, 07 Jan 2000 06:07:00 -0000 [thread overview]
Message-ID: <3875F4A2.23B8983B@evsx.com> (raw)
In-Reply-To: <91ad4.611$CJ1.22204@dfiatx1-snr1.gtei.net>
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
WARNING: multiple messages have this Message-ID
From: Eric DeVolder <devolder@evsx.com>
To: Rudy Folden <rfolden@gte.net>
Cc: help-gcc@gnu.org
Subject: Re: Linker Sections and OBJDUMP
Date: Sat, 01 Apr 2000 00:00:00 -0000 [thread overview]
Message-ID: <3875F4A2.23B8983B@evsx.com> (raw)
Message-ID: <20000401000000.mNgoT02Odr3mzY1wvT3uWy9ebPyD4p6cqNyCn1SU50s@z> (raw)
In-Reply-To: <91ad4.611$CJ1.22204@dfiatx1-snr1.gtei.net>
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
next prev parent reply other threads:[~2000-01-07 6:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-01-06 16:06 Rudy Folden
2000-01-07 6:07 ` Eric DeVolder [this message]
2000-04-01 0:00 ` Eric DeVolder
2000-04-01 0:00 ` Rudy Folden
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3875F4A2.23B8983B@evsx.com \
--to=devolder@evsx.com \
--cc=help-gcc@gnu.org \
--cc=rfolden@gte.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).