[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
possible minor bug in ld
From: |
Smith, Ken (G.) |
Subject: |
possible minor bug in ld |
Date: |
Wed, 3 Apr 2002 16:14:03 -0500 |
Machine architecture: x86
OS: Windows 2000 sp 2
Environment: Cygwin
Binutils is presumably compiled in the following way but my version of ld is
2.11.2.
from http://h8300-hms.sourceforge.net/
binutils
tar xfj binutils-2.12.tar.bz2
cd binutils-2.12
mkdir objdir
cd objdir
../configure --prefix=/usr/local --target=h8300-hms
gmake CFLAGS="-O2 -fomit-frame-pointer" all
gmake install #this has to be done by root
Output from `h8300-hms-ld --version`:
GNU ld 2.11.2
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
Supported emulations:
h8300
h8300h
h8300s
Description of suspicious behavior
command lines
h8300-hms-gcc -c -o main.o main.c
h8300-hms-ld tiny.xcl -oformat=srec -o main.mot main.o
tiny.xcl is attached. It is a slightly modified (not yet to my chips
specifications) file received from a member of address@hidden
I am under the impression that the -oformat=srec overrides any output format
specification. However, the output in main.mot is not an s-record but a coff
object. I am new to using the features of the linker. Until now, I have been
letting gcc do the invoking on my behalf. After a short perusal of "ld: the
GNU linker", I have learned that I need only supply a -T before the linker
script file and I get an s-record as the linker script specifies without the
-oformat=srec command line option. Therefore, I am only reporting this in the
hopes that it will be useful. Perhaps it is not even a bug but intentional.
Finally, here is the output from `h8300-hms-ld --verbose`
GNU ld version 2.11.2 (with BFD 2.11.2)
Supported emulations:
h8300
h8300h
h8300s
using internal linker script:
==================================================
OUTPUT_FORMAT("coff-h8300")
OUTPUT_ARCH(h8300)
ENTRY("_start")
MEMORY
{
/* 0xc4 is a magic entry. We should have the linker just
skip over it one day... */
vectors : o = 0x0000, l = 0xc4
magicvectors : o = 0xc4, l = 0x3c
ram : o = 0x0100, l = 0xfdfc
/* The stack starts at the top of main ram. */
topram : o = 0xfefc, l = 0x4
/* At the very top of the address space is the 8-bit area. */
eight : o = 0xff00, l = 0x100
}
SECTIONS
{
.vectors :
{
/* Use something like this to place a specific
function's address into the vector table.
SHORT (ABSOLUTE (_foobar)). */
*(.vectors)
} > vectors
.text :
{
*(.rodata)
*(.text)
*(.strings)
_etext = . ;
} > ram
.tors :
{
___ctors = . ;
*(.ctors)
___ctors_end = . ;
___dtors = . ;
*(.dtors)
___dtors_end = . ;
} > ram
.data :
{
*(.data)
*(.tiny)
_edata = . ;
} > ram
.bss :
{
_bss_start = . ;
*(.bss)
*(COMMON)
_end = . ;
} >ram
.stack :
{
_stack = . ;
*(.stack)
} > topram
.eight :
{
*(.eight)
} > eight
.stab 0 (NOLOAD) :
{
[ .stab ]
}
.stabstr 0 (NOLOAD) :
{
[ .stabstr ]
}
}
==================================================
tiny.xcl
Description: Binary data
main.c
Description: Binary data
- possible minor bug in ld,
Smith, Ken (G.) <=