--- /dev/null
+/*doc*
+@section Core files
+Buff output this facinating topic
+*/
+
+#include "sysdep.h"
+#include "bfd.h"
+#include "libbfd.h"
+
+/** Some core file info commands */
+
+/*proto*i bfd_core_file_failing_command
+Returns a read-only string explaining what program was running when
+it failed and produced the core file being read
+
+*; PROTO(CONST char *, bfd_core_file_failing_command, (bfd *));
+*/
+
+CONST char *
+DEFUN(bfd_core_file_failing_command,(abfd),
+ bfd *abfd)
+{
+ if (abfd->format != bfd_core) {
+ bfd_error = invalid_operation;
+ return NULL;
+ }
+ return BFD_SEND (abfd, _core_file_failing_command, (abfd));
+}
+
+/*proto* bfd_core_file_failing_signal
+Returns the signal number which caused the core dump which generated
+the file the bfd is attatched to.
+
+*; PROTO(int, bfd_core_file_failing_signal, (bfd *));
+*/
+int
+bfd_core_file_failing_signal (abfd)
+ bfd *abfd;
+{
+ if (abfd->format != bfd_core) {
+ bfd_error = invalid_operation;
+ return 0;
+ }
+ return BFD_SEND (abfd, _core_file_failing_signal, (abfd));
+}
+
+
+/*proto* core_file_matches_executable_p
+Returns @code{true} if the core file attatched to @var{core_bfd} was
+generated by a run of the executable file attatched to @var{exec_bfd},
+or else @code{false}.
+*; PROTO(boolean, core_file_matches_executable_p,
+ (bfd *core_bfd, bfd *exec_bfd));
+*/
+boolean
+core_file_matches_executable_p (core_bfd, exec_bfd)
+ bfd *core_bfd, *exec_bfd;
+{
+ if ((core_bfd->format != bfd_core) || (exec_bfd->format != bfd_object)) {
+ bfd_error = wrong_format;
+ return false;
+ }
+
+ return BFD_SEND (core_bfd, _core_file_matches_executable_p, (core_bfd, exec_bfd));
+}
--- /dev/null
+/*doc*
+@section Relocations
+
+Bfd maintains relocations in much the same was as it maintains
+symbols; they are left alone until required, then read in en-mass and
+traslated into an internal form. There is a common routine
+@code{bfd_perform_relocation} which acts upon the canonical form to to
+the actual fixup.
+
+Note that relocations are maintained on a per section basis, whilst
+symbols are maintained on a per bfd basis.
+
+All a back end has to do to fit the bfd interface is to create as many
+@code{struct reloc_cache_entry} as there are relocations in a
+particuar section, and fill in the right bits:
+
+@menu
+* typedef arelent::
+* reloc handling functions::
+@end menu
+
+*/
+#include "sysdep.h"
+#include "bfd.h"
+#include "libbfd.h"
+/*doc
+*node typedef arelent, Relocations, reloc handling functions, Relocations
+@section typedef arelent
+
+
+*/
+
+/*proto* bfd_perform_relocation
+The relocation routine returns as a status an enumerated type:
+
+*+++
+
+$typedef enum bfd_reloc_status {
+No errors detected
+
+$ bfd_reloc_ok,
+
+The relocation was performed, but there was an overflow.
+
+$ bfd_reloc_overflow,
+
+The address to relocate was not within the section supplied
+
+$ bfd_reloc_outofrange,
+
+Used by special functions
+
+$ bfd_reloc_continue,
+
+Unused
+
+$ bfd_reloc_notsupported,
+
+Unsupported relocation size requested.
+
+$ bfd_reloc_other,
+
+The symbol to relocate against was undefined.
+
+$ bfd_reloc_undefined,
+
+The relocaction was performed, but may not be ok - presently generated
+only when linking i960 coff files with i960 b.out symbols.
+
+$ bfd_reloc_dangerous
+$ }
+$ bfd_reloc_status_enum_type;
+
+*---
+
+*/
+
+/*proto*
+
+*+++
+
+$typedef struct reloc_cache_entry
+${
+
+A pointer into the canonical table of pointers
+
+$ struct symbol_cache_entry **sym_ptr_ptr;
+
+offset in section
+
+$ rawdata_offset address;
+
+addend for relocation value
+
+$ bfd_vma addend;
+
+if sym is null this is the section
+
+$ struct sec *section;
+
+Pointer to how to perform the required relocation
+
+$ struct reloc_howto_struct *howto;
+$} arelent;
+
+*---
+
+*/
+
+/*doc*
+@table @code
+@item sym_ptr_ptr
+The symbol table pointer points to a pointer to the symbol ascociated with the
+relocation request. This would naturaly be the pointer into the table
+returned by the back end's get_symtab action. @xref{Symbols}. The
+symbol is referenced through a pointer to a pointer so that tools like
+the linker can fixup all the symbols of the same name by modifying
+only one pointer. The relocation routine looks in the symbol and uses
+the base of the section the symbol is attatched to and the value of
+the symbol as the initial relocation offset. If the symbol pointer is
+zero, then the section provided is looked up.
+@item address
+The address field gives the offset in bytes from the base of the
+section data which owns the relocation record to the first byte of
+relocatable information. The actual data relocated will be relative to
+this point - for example, a relocation type which modifies the bottom
+two bytes of a four byte word would not touch the first byte pointed
+to in a big endian world.
+@item addend
+The addend is a value provided by the back end to be added (!) to the
+relocation offset. It's interpretation is dependent upon the howto.
+For example, on the 68k the code:
+
+*+
+ char foo[];
+ main()
+ {
+ return foo[0x12345678];
+ }
+*-
+Could be compiled into:
+
+*+
+ linkw fp,#-4
+ moveb @@#12345678,d0
+ extbl d0
+ unlk fp
+ rts
+*-
+
+This could create a reloc pointing to foo, but leave the offset in the data
+(something like)
+
+*+
+RELOCATION RECORDS FOR [.text]:
+OFFSET TYPE VALUE
+00000006 32 _foo
+
+00000000 4e56 fffc ; linkw fp,#-4
+00000004 1039 1234 5678 ; moveb @@#12345678,d0
+0000000a 49c0 ; extbl d0
+0000000c 4e5e ; unlk fp
+0000000e 4e75 ; rts
+*-
+Using coff and an 88k, some instructions don't have enough space in them to
+represent the full address range, and pointers have to be loaded in
+two parts. So you'd get something like:
+
+*+
+ or.u r13,r0,hi16(_foo+0x12345678)
+ ld.b r2,r13,lo16(_foo+0x12345678)
+ jmp r1
+*-
+This whould create two relocs, both pointing to _foo, and with 0x12340000
+in their addend field. The data would consist of:
+
+*+
+
+RELOCATION RECORDS FOR [.text]:
+OFFSET TYPE VALUE
+00000002 HVRT16 _foo+0x12340000
+00000006 LVRT16 _foo+0x12340000
+
+00000000 5da05678 ; or.u r13,r0,0x5678
+00000004 1c4d5678 ; ld.b r2,r13,0x5678
+00000008 f400c001 ; jmp r1
+*-
+The relocation routine digs out the value from the data, adds it to
+the addend to get the original offset and then adds the value of _foo.
+Note that all 32 bits have to be kept around somewhere, to cope with
+carry from bit 15 to bit 16.
+
+On further example is the sparc and the a.out format. The sparc has a
+similar problem to the 88k, in that some instructions don't have
+room for an entire offset, but on the sparc the parts are created odd
+sized lumps. The designers of the a.out format chose not to use the
+data within the section for storing part of the offset; all the offset
+is kept within the reloc. Any thing in the data should be ignored.
+
+*+
+ save %sp,-112,%sp
+ sethi %hi(_foo+0x12345678),%g2
+ ldsb [%g2+%lo(_foo+0x12345678)],%i0
+ ret
+ restore
+*-
+Both relocs contains a pointer to foo, and the offsets would contain junk.
+
+*+
+RELOCATION RECORDS FOR [.text]:
+OFFSET TYPE VALUE
+00000004 HI22 _foo+0x12345678
+00000008 LO10 _foo+0x12345678
+
+00000000 9de3bf90 ; save %sp,-112,%sp
+00000004 05000000 ; sethi %hi(_foo+0),%g2
+00000008 f048a000 ; ldsb [%g2+%lo(_foo+0)],%i0
+0000000c 81c7e008 ; ret
+00000010 81e80000 ; restore
+*-
+@item section
+The section field is only used when the symbol pointer field is null.
+It supplies the section into which the data should be relocated. The
+field's main use comes from assemblers which do most of the symbol fixups
+themselves; an assembler may take an internal reference to a label,
+but since it knows where the label is, it can turn the relocation
+request from a symbol lookup into a section relative relocation - the
+relocation emitted has no symbol, just a section to relocate against.
+
+I'm not sure what it means when both a symbol pointer an a section
+pointer are present. Some formats use this sort of mechanism to
+describe PIC relocations, but bfd can't to that sort of thing yet.
+@item howto
+The howto field can be imagined as a relocation instruction. It is a
+pointer to a struct which contains information on what to do with all
+the other information in the reloc record and data section. A back end
+would normally have a relocation instruction set and turn relocations
+into pointers to the correct structure on input - but it would be
+possible to create each howto field on demand.
+@end table
+*/
+
+
+/*proto* reloc_howto_type
+The @code{reloc_howto_type} is a structure which contains all the
+information that bfd needs to know to tie up a back end's data.
+
+*+++
+
+$typedef CONST struct reloc_howto_struct
+${
+The type field has mainly a documetary use - the back end can to what
+it wants with it, though the normally the back end's external idea of
+what a reloc number would be would be stored in this field. For
+example, the a PC relative word relocation in a coff environment would
+have the type 023 - because that's what the outside world calls a
+R_PCRWORD reloc.
+
+$ unsigned int type;
+
+The value the final relocation is shifted right by. This drops
+unwanted data from the relocation.
+
+$ unsigned int rightshift;
+
+The size of the item to be relocated - 0, is one byte, 1 is 2 bytes, 3
+is four bytes.
+
+$ unsigned int size;
+
+Now obsolete
+
+$ unsigned int bitsize;
+
+Notes that the relocation is relative to the location in the data
+section of the addend. The relocation function will subtract from the
+relocation value the address of the location being relocated.
+
+$ boolean pc_relative;
+
+Now obsolete
+
+$ unsigned int bitpos;
+
+Now obsolete
+
+$ boolean absolute;
+
+Causes the relocation routine to return an error if overflow is
+detected when relocating.
+
+$ boolean complain_on_overflow;
+
+If this field is non null, then the supplied function is called rather
+than the normal function. This allows really strange relocation
+methods to be accomodated (eg, i960 callj instructions).
+
+$ bfd_reloc_status_enum_type (*special_function)();
+
+The textual name of the relocation type.
+
+$ char *name;
+
+When performing a partial link, some formats must modify the
+relocations rather than the data - this flag signals this.
+
+$ boolean partial_inplace;
+
+The src_mask is used to select what parts of the read in data are to
+be used in the relocation sum. Eg, if this was an 8 bit bit of data
+which we read and relocated, this would be 0x000000ff. When we have
+relocs which have an addend, such as sun4 extended relocs, the value
+in the offset part of a relocating field is garbage so we never use
+it. In this case the mask would be 0x00000000.
+
+$ bfd_word src_mask;
+The dst_mask is what parts of the instruction are replaced into the
+instruction. In most cases src_mask == dst_mask, except in the above
+special case, where dst_mask would be 0x000000ff, and src_mask would
+be 0x00000000.
+
+$ bfd_word dst_mask;
+
+When some formats create PC relative instructions, they leave the
+value of the pc of the place being relocated in the offset slot of the
+instruction, so that a PC relative relocation can be made just by
+adding in an ordinary offset (eg sun3 a.out). Some formats leave the
+displacement part of an instruction empty (eg m88k bcs), this flag
+signals the fact.
+
+$ boolean pcrel_offset;
+$} reloc_howto_type;
+*---
+
+*/
+
+/*proto* HOWTO
+The HOWTO define is horrible and will go away.
+*+
+#define HOWTO(C, R,S,B, P, BI, ABS, O, SF, NAME, INPLACE, MASKSRC, MASKDST, PC) \
+ {(unsigned)C,R,S,B, P, BI, ABS,O,SF,NAME,INPLACE,MASKSRC,MASKDST,PC}
+*-
+
+*/
+
+/*proto* reloc_chain
+*+
+typedef unsigned char bfd_byte;
+
+typedef struct relent_chain {
+ arelent relent;
+ struct relent_chain *next;
+} arelent_chain;
+
+*-
+
+*/
+
+
+
+/*proto*
+If an output_bfd is supplied to this function the generated image
+will be relocatable, the relocations are copied to the output file
+after they have been changed to reflect the new state of the world.
+There are two ways of reflecting the results of partial linkage in an
+output file; by modifying the output data in place, and by modifying
+the relocation record. Some native formats (eg basic a.out and basic
+coff) have no way of specifying an addend in the relocation type, so
+the addend has to go in the output data. This is no big deal since in
+these formats the output data slot will always be big enough for the
+addend. Complex reloc types with addends were invented to solve just
+this problem.
+*; PROTO(bfd_reloc_status_enum_type,
+ bfd_perform_relocation,
+ (bfd * abfd,
+ arelent *reloc_entry,
+ PTR data,
+ asection *input_section,
+ bfd *output_bfd));
+*/
+
+
+bfd_reloc_status_enum_type
+DEFUN(bfd_perform_relocation,(abfd,
+ reloc_entry,
+ data,
+ input_section,
+ output_bfd),
+ bfd *abfd AND
+ arelent *reloc_entry AND
+ PTR data AND
+ asection *input_section AND
+ bfd *output_bfd)
+{
+ bfd_vma relocation;
+ bfd_reloc_status_enum_type flag = bfd_reloc_ok;
+ bfd_vma addr = reloc_entry->address ;
+ bfd_vma output_base = 0;
+ reloc_howto_type *howto = reloc_entry->howto;
+ asection *reloc_target_output_section;
+ asection *reloc_target_input_section;
+ asymbol *symbol;
+
+ if (reloc_entry->sym_ptr_ptr) {
+ symbol = *( reloc_entry->sym_ptr_ptr);
+ if ((symbol->flags & BSF_UNDEFINED) && output_bfd == (bfd *)NULL) {
+ flag = bfd_reloc_undefined;
+ }
+ }
+ else {
+ symbol = (asymbol*)NULL;
+ }
+
+ if (howto->special_function){
+ bfd_reloc_status_enum_type cont;
+ cont = howto->special_function(abfd,
+ reloc_entry,
+ symbol,
+ data,
+ input_section);
+ if (cont != bfd_reloc_continue) return cont;
+ }
+
+ /*
+ Work out which section the relocation is targetted at and the
+ initial relocation command value.
+ */
+
+
+ if (symbol != (asymbol *)NULL){
+ if (symbol->flags & BSF_FORT_COMM) {
+ relocation = 0;
+ }
+ else {
+ relocation = symbol->value;
+ }
+ if (symbol->section != (asection *)NULL)
+ {
+ reloc_target_input_section = symbol->section;
+ }
+ else {
+ reloc_target_input_section = (asection *)NULL;
+ }
+ }
+ else if (reloc_entry->section != (asection *)NULL)
+ {
+ relocation = 0;
+ reloc_target_input_section = reloc_entry->section;
+ }
+ else {
+ relocation = 0;
+ reloc_target_input_section = (asection *)NULL;
+ }
+
+
+ if (reloc_target_input_section != (asection *)NULL) {
+
+ reloc_target_output_section =
+ reloc_target_input_section->output_section;
+
+ if (output_bfd && howto->partial_inplace==false) {
+ output_base = 0;
+ }
+ else {
+ output_base = reloc_target_output_section->vma;
+
+ }
+
+ relocation += output_base + reloc_target_input_section->output_offset;
+ }
+
+ relocation += reloc_entry->addend ;
+
+
+ if(reloc_entry->address > (bfd_vma)(input_section->size))
+ {
+ return bfd_reloc_outofrange;
+ }
+
+
+ if (howto->pc_relative == true)
+ {
+ /*
+ Anything which started out as pc relative should end up that
+ way too.
+
+ There are two ways we can see a pcrel instruction. Sometimes
+ the pcrel displacement has been partially calculated, it
+ includes the distance from the start of the section to the
+ instruction in it (eg sun3), and sometimes the field is
+ totally blank - eg m88kbcs.
+ */
+
+
+ relocation -=
+ output_base + input_section->output_offset;
+
+ if (howto->pcrel_offset == true) {
+ relocation -= reloc_entry->address;
+ }
+
+ }
+
+ if (output_bfd!= (bfd *)NULL) {
+ if ( howto->partial_inplace == false) {
+ /*
+ This is a partial relocation, and we want to apply the relocation
+ to the reloc entry rather than the raw data. Modify the reloc
+ inplace to reflect what we now know.
+ */
+ reloc_entry->addend = relocation ;
+ reloc_entry->section = reloc_target_input_section;
+ if (reloc_target_input_section != (asection *)NULL) {
+ /* If we know the output section we can forget the symbol */
+ reloc_entry->sym_ptr_ptr = (asymbol**)NULL;
+ }
+ reloc_entry->address +=
+ input_section->output_offset;
+ return flag;
+ }
+ else
+ {
+ /* This is a partial relocation, but inplace, so modify the
+ reloc record a bit
+ */
+
+ }
+ }
+
+ reloc_entry->addend = 0;
+
+
+ /*
+ Either we are relocating all the way, or we don't want to apply
+ the relocation to the reloc entry (probably because there isn't
+ any room in the output format to describe addends to relocs)
+ */
+ relocation >>= howto->rightshift;
+
+ /* Shift everything up to where it's going to be used */
+
+ relocation <<= howto->bitpos;
+
+ /* Wait for the day when all have the mask in them */
+
+ /* What we do:
+ i instruction to be left alone
+ o offset within instruction
+ r relocation offset to apply
+ S src mask
+ D dst mask
+ N ~dst mask
+ A part 1
+ B part 2
+ R result
+
+ Do this:
+ i i i i i o o o o o from bfd_get<size>
+ and S S S S S to get the size offset we want
+ + r r r r r r r r r r to get the final value to place
+ and D D D D D to chop to right size
+ -----------------------
+ A A A A A
+ And this:
+ ... i i i i i o o o o o from bfd_get<size>
+ and N N N N N get instruction
+ -----------------------
+ ... B B B B B
+
+ And then:
+ B B B B B
+ or A A A A A
+ -----------------------
+ R R R R R R R R R R put into bfd_put<size>
+ */
+
+#define DOIT(x) \
+ x = ( (x & ~howto->dst_mask) | (((x & howto->src_mask) + relocation) & howto->dst_mask))
+
+ switch (howto->size)
+ {
+ case 0:
+ {
+ char x = bfd_get_8(abfd, (char *)data + addr);
+ DOIT(x);
+ bfd_put_8(abfd,x, (unsigned char *) data + addr);
+ }
+ break;
+
+ case 1:
+ {
+ short x = bfd_get_16(abfd, (bfd_byte *)data + addr);
+ DOIT(x);
+ bfd_put_16(abfd, x, (unsigned char *)data + addr);
+ }
+ break;
+ case 2:
+ {
+ long x = bfd_get_32(abfd, (bfd_byte *) data + addr);
+ DOIT(x);
+ bfd_put_32(abfd,x, (bfd_byte *)data + addr);
+ }
+ break;
+ case 3:
+ /* Do nothing */
+ break;
+ default:
+ return bfd_reloc_other;
+ }
+
+ return flag;
+}
--- /dev/null
+/*doc*
+@section Sections
+Sections are supported in bfd in @code{section.c}.
+
+The raw data contained within a bfd is maintained through the section
+abstraction. A single bfd may have any number of sections, and keeps
+hold of them by pointing to the first, each one points to the next in
+the list.
+
+@menu
+* Section Input::
+* Section Output::
+* typedef asection::
+* section prototypes::
+@end menu
+
+@node Section Input, Section Output,,Sections
+@comment node-name, next, previous, up
+@subsection Section Input
+When a bfd is opened for reading, the section structures are created
+and attatched to the bfd.
+
+Each section has a name which describes the section in the outside
+world - for example, @code{a.out} would contain at least three
+sections, called @code{.text}, @code{.data} and @code{.bss}.
+
+Sometimes a bfd will contain more than the 'natural' number of
+sections. A back end may attatch other sections containing constructor
+data, or an application may add a section (using bfd_make_section) to
+the sections attatched to an already open bfd. For example, the linker
+creates a supernumary section @code{COMMON} for each input file's bfd
+to hold information about common storage.
+
+The raw data is not necessarily read in at the same time as the
+section descriptor is created. Some targets may leave the data in
+place until a @code{bfd_get_section_contents} call is made. Other back
+ends may read in all the data at once - For example; an S-record file
+has to be read once to determine the size of the data. An IEEE-695
+file doesn't contain raw data in sections, but data and relocation
+expressions intermixed, so the data area has to be parsed to get out
+the data and relocations.
+
+@node Section Output,typedef asection,Section Input,Sections
+@subsection Section Output
+To write a new object style bfd, the various sections to be written
+have to be created. They are attatched to the bfd in the same way as
+input sections, data is written to the sections using
+@code{bfd_set_section_contents}.
+
+The linker uses the fields @code{output_section} and
+@code{output_offset} to create an output file.
+
+The data to be written comes from input sections attatched to the
+output sections. The output section structure can be considered a
+filter for the input section, the output section determines the vma of
+the output data and the name, but the input section determines the
+offset into the output section of the data to be written.
+
+Eg to create a section "O", starting at 0x100, 0x123 long, containing two
+subsections, "A" at offset 0x0 (ie at vma 0x100) and "B" at offset
+0x20 (ie at vma 0x120) the structures would look like:
+
+*+
+
+ section name "A"
+ output_offset 0x00
+ size 0x20
+ output_section -----------> section name "O"
+ | vma 0x100
+ section name "B" | size 0x123
+ output_offset 0x20 |
+ size 0x103 |
+ output_section --------|
+
+*-
+
+*/
+
+
+#include "sysdep.h"
+#include "bfd.h"
+#include "libbfd.h"
+
+
+/*doc*
+@node typedef asection,section prototypes,Section Output,Sections
+@subsection typedef asection
+*/
+
+/*proto*
+The shape of a section struct:
+
+*+++
+
+$typedef struct sec {
+
+The name of the section, the name isn't a copy, the pointer is
+the same as that passed to bfd_make_section.
+
+$ CONST char *name;
+
+The next section in the list belonging to the bfd, or NULL.
+
+$ struct sec *next;
+
+The field flags contains attributes of the section. Some of these
+flags are read in from the object file, and some are synthesized from
+other information.
+
+$flagword flags;
+
+
+$#define SEC_NO_FLAGS 0x000
+
+Tells the OS to allocate space for this section when loaded.
+This would clear for a section containing debug information only.
+
+$#define SEC_ALLOC 0x001
+
+Tells the OS to load the section from the file when loading.
+This would be clear for a .bss section
+
+$#define SEC_LOAD 0x002
+
+The section contains data still to be relocated, so there will be some
+relocation information too.
+
+$#define SEC_RELOC 0x004
+
+Obsolete ?
+
+$#define SEC_BALIGN 0x008
+
+A signal to the OS that the section contains read only data.
+
+$#define SEC_READONLY 0x010
+
+The section contains code only.
+
+$#define SEC_CODE 0x020
+
+The section contains data only.
+
+$#define SEC_DATA 0x040
+
+The section will reside in ROM.
+
+$#define SEC_ROM 0x080
+
+The section contains constructor information. This section type is
+used by the linker to create lists of constructors and destructors
+used by @code{g++}. When a back end sees a symbol which should be used
+in a constructor list, it creates a new section for the type of name
+(eg @code{__CTOR_LIST__}), attatches the symbol to it and builds a
+relocation. To build the lists of constructors, all the linker has to
+to is catenate all the sections called @code{__CTOR_LIST__} and
+relocte the data contained within - exactly the operations it would
+peform on standard data.
+
+$#define SEC_CONSTRUCTOR 0x100
+
+The section has contents - a bss section could be
+@code{SEC_ALLOC} | @code{SEC_HAS_CONTENTS}, a debug section could be
+@code{SEC_HAS_CONTENTS}
+
+$#define SEC_HAS_CONTENTS 0x200
+
+An instruction to the linker not to output sections containing
+this flag even if they have information which would normally be written.
+
+$#define SEC_NEVER_LOAD 0x400
+
+The base address of the section in the address space of the target.
+
+$ bfd_vma vma;
+
+The size of the section in bytes of the loaded section. This contains
+a value even if the section has no contents (eg, the size of @code{.bss}).
+
+$ bfd_size_type size;
+
+If this section is going to be output, then this value is the
+offset into the output section of the first byte in the input
+section. Eg, if this was going to start at the 100th byte in the
+output section, this value would be 100.
+
+$ bfd_vma output_offset;
+
+The output section through which to map on output.
+
+$ struct sec *output_section;
+
+The alignment requirement of the section, as an exponent - eg 3
+aligns to 2^3 (or 8)
+
+$ unsigned int alignment_power;
+
+If an input section, a pointer to a vector of relocation records for
+the data in this section.
+
+$ struct reloc_cache_entry *relocation;
+
+If an output section, a pointer to a vector of pointers to
+relocation records for the data in this section.
+
+$ struct reloc_cache_entry **orelocation;
+
+The number of relocation records in one of the above
+
+$ unsigned reloc_count;
+
+Which section is it 0..nth
+
+$ int index;
+
+Information below is back end specific - and not always used or
+updated
+
+File position of section data
+
+$ file_ptr filepos;
+File position of relocation info
+
+$ file_ptr rel_filepos;
+
+File position of line data
+
+$ file_ptr line_filepos;
+
+Pointer to data for applications
+
+$ PTR userdata;
+
+$ struct lang_output_section *otheruserdata;
+
+Attached line number information
+
+$ alent *lineno;
+Number of line number records
+
+$ unsigned int lineno_count;
+
+When a section is being output, this value changes as more
+linenumbers are written out
+
+$ file_ptr moving_line_filepos;
+
+what the section number is in the target world
+
+$ unsigned int target_index;
+
+$ PTR used_by_bfd;
+
+If this is a constructor section then here is a list of the
+relocations created to relocate items within it.
+
+$ struct relent_chain *constructor_chain;
+
+The bfd which owns the section.
+
+$ bfd *owner;
+
+$} asection ;
+
+*---
+
+*/
+
+/*doc*
+@node section prototypes,Section,typedef section,Sections
+@subsection section prototypes
+
+*/
+/*proto* bfd_get_section_by_name
+Runs through the provided @var{abfd} and returns the @code{asection}
+who's name matches that provided, otherwise NULL. @xref{Sections}, for more information.
+
+*; PROTO(asection *, bfd_get_section_by_name,
+ (bfd *abfd, CONST char *name));
+*/
+asection *
+DEFUN(bfd_get_section_by_name,(abfd, name),
+ bfd *abfd AND
+ CONST char *name)
+{
+ asection *sect;
+
+ for (sect = abfd->sections; sect != NULL; sect = sect->next)
+ if (!strcmp (sect->name, name)) return sect;
+ return NULL;
+}
+
+
+/*proto* bfd_make_section
+This function creates a new empty section called @var{name} and attatches it
+to the end of the chain of sections for @var{bfd}. An attempt to
+create a section with a name which is already in use, returns the old
+section by that name instead.
+
+Possible errors are:
+@table @code
+@item invalid_operation
+If output has already started for this bfd.
+@item no_memory
+If obstack alloc fails.
+@end table
+
+*; PROTO(asection *, bfd_make_section, (bfd *, CONST char *name));
+*/
+
+
+
+sec_ptr
+DEFUN(bfd_make_section,(abfd, name),
+ bfd *abfd AND
+ CONST char * name)
+{
+ asection *newsect;
+ asection ** prev = &abfd->sections;
+ asection * sect = abfd->sections;
+
+ if (abfd->output_has_begun) {
+ bfd_error = invalid_operation;
+ return NULL;
+ }
+
+ while (sect) {
+ if (!strcmp(sect->name, name)) return sect;
+ prev = §->next;
+ sect = sect->next;
+ }
+
+ newsect = (asection *) bfd_zalloc(abfd, sizeof (asection));
+ if (newsect == NULL) {
+ bfd_error = no_memory;
+ return NULL;
+ }
+
+ newsect->name = name;
+ newsect->index = abfd->section_count++;
+ newsect->flags = SEC_NO_FLAGS;
+
+ newsect->userdata = 0;
+ newsect->next = (asection *)NULL;
+ newsect->relocation = (arelent *)NULL;
+ newsect->reloc_count = 0;
+ newsect->line_filepos =0;
+ newsect->owner = abfd;
+ if (BFD_SEND (abfd, _new_section_hook, (abfd, newsect)) != true) {
+ free (newsect);
+ return NULL;
+ }
+
+ *prev = newsect;
+ return newsect;
+}
+
+
+/*proto* bfd_set_section_flags
+Attempts to set the attributes of the section named in the bfd
+supplied to the value. Returns true on success, false on error.
+Possible error returns are:
+@table @code
+@item invalid operation
+The section cannot have one or more of the attributes requested. For
+example, a .bss section in @code{a.out} may not have the
+@code{SEC_HAS_CONTENTS} field set.
+@end table
+
+*; PROTO(boolean, bfd_set_section_flags,
+ (bfd *, asection *, flagword));
+*/
+
+boolean
+DEFUN(bfd_set_section_flags,(abfd, section, flags),
+ bfd *abfd AND
+ sec_ptr section AND
+ flagword flags)
+{
+ if ((flags & bfd_applicable_section_flags (abfd)) != flags) {
+ bfd_error = invalid_operation;
+ return false;
+ }
+
+ section->flags = flags;
+ return true;
+}
+
+
+/*proto* bfd_map_over_sections
+Calls the provided function @var{func} for each section attatched to
+the bfd @var{abfd}, passing @var{obj} as an argument. The function
+will be called as if by
+
+@example
+ func(abfd, the_section, obj);
+@end example
+
+
+*; PROTO(void, bfd_map_over_sections,
+ (bfd *abfd, void (*func)(), PTR obj));
+
+This is the prefered method for iterating over sections, an
+alternative would be to use a loop:
+
+@example
+ section *p;
+ for (p = abfd->sections; p != NULL; p = p->next)
+ func(abfd, p, ...)
+@end example
+*/
+
+/*VARARGS2*/
+void
+DEFUN(bfd_map_over_sections,(abfd, operation, user_storage),
+ bfd *abfd AND
+ void (*operation)() AND
+ PTR user_storage)
+{
+ asection *sect;
+ int i = 0;
+
+ for (sect = abfd->sections; sect != NULL; i++, sect = sect->next)
+ (*operation) (abfd, sect, user_storage);
+
+ if (i != abfd->section_count) /* Debugging */
+ abort();
+}
+
+
+/*proto* bfd_set_section_size
+Sets @var{section} to the size @var{val}. If the operation is ok, then
+@code{true} is returned, else @code{false}.
+
+Possible error returns:
+@table @code
+@item invalid_operation
+Writing has started to the bfd, so setting the size is invalid
+@end table
+
+*; PROTO(boolean, bfd_set_section_size,
+ (bfd *, asection *, bfd_size_type val));
+*/
+
+boolean
+DEFUN(bfd_set_section_size,(abfd, ptr, val),
+ bfd *abfd AND
+ sec_ptr ptr AND
+ unsigned long val)
+{
+ /* Once you've started writing to any section you cannot create or change
+ the size of any others. */
+
+ if (abfd->output_has_begun) {
+ bfd_error = invalid_operation;
+ return false;
+ }
+
+ ptr->size = val;
+
+ return true;
+}
+
+/*proto* bfd_set_section_contents
+Sets the contents of the section @var{section} in bfd @var{abfd} to
+the data starting in memory at @var{data}. The data is written to the
+output section starting at offset @var{offset} for @var{count} bytes.
+
+Normally @code{true} is returned, else @code{false}. Possible error
+returns are:
+@table @code
+@item no_contents
+The output section does not have the @code{SEC_HAS_CONTENTS}
+attribute, so nothing can be written to it.
+@item and some more too
+@end table
+This routine is front end to the back end function @code{_bfd_set_section_contents}.
+
+*; PROTO(boolean, bfd_set_section_contents,
+ (bfd *abfd,
+ asection *section,
+ PTR data,
+ file_ptr offset,
+ bfd_size_type count));
+
+*/
+
+boolean
+DEFUN(bfd_set_section_contents,(abfd, section, location, offset, count),
+ bfd *abfd AND
+ sec_ptr section AND
+ PTR location AND
+ file_ptr offset AND
+ bfd_size_type count)
+{
+ if (!(bfd_get_section_flags(abfd, section) & SEC_HAS_CONTENTS))
+ {
+ bfd_error = no_contents;
+ return(false);
+ }
+
+ if (BFD_SEND (abfd, _bfd_set_section_contents,
+ (abfd, section, location, offset, count)))
+ {
+ abfd->output_has_begun = true;
+ return true;
+ }
+
+ return false;
+}
+
+/*proto* bfd_get_section_contents
+This function reads data from @var{section} in bfd @var{abfd} into
+memory starting at @var{location}. The data is read at an offset of
+@var{offset} from the start of the input section, and is read for
+@var{count} bytes.
+
+If the contents of a constuctor with the @code{SEC_CONSTUCTOR} flag
+set are requested, then the @var{location} is filled with zeroes.
+
+If no errors occur, @code{true} is returned, else @code{false}.
+Possible errors are:
+
+@table @code
+@item unknown yet
+@end table
+
+*; PROTO(boolean, bfd_get_section_contents,
+ (bfd *abfd, asection *section, PTR location,
+ file_ptr offset, bfd_size_type count));
+
+
+*/
+boolean
+DEFUN(bfd_get_section_contents,(abfd, section, location, offset, count),
+ bfd *abfd AND
+ sec_ptr section AND
+ PTR location AND
+ file_ptr offset AND
+ bfd_size_type count)
+{
+ if (section->flags & SEC_CONSTRUCTOR)
+ {
+ memset(location, 0, (unsigned)count);
+ return true;
+ }
+ else
+ {
+ return (BFD_SEND (abfd, _bfd_get_section_contents,
+ (abfd, section, location, offset, count)));
+ }
+}
+
projects / binutils-gdb.git / commitdiff