bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bug found when linking to S-RECORD type


From: Nico Langenberg
Subject: Bug found when linking to S-RECORD type
Date: Thu, 3 Jun 2004 15:46:11 +0200

Hello,

I have found a possible bug. I have a workaround for it, but please take
a look at the following problem.

First the versions I have used to generate my output.
GNU package: gnuh8v0401-elf.exe from http://www.kpitgnutools.com

h8300-elf-ld --version
GNU ld version GNUH8_v0401 20030612
Copyright 2002 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.

h8300-elf-gcc --version
h8300-elf-gcc (GCC) 3.3-GNUH8_v0401
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

h8300-elf-as --version
GNU assembler GNUH8_v0401 20030612
Copyright 2002 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.
This assembler was configured for a target of `h8300-elf'.

My OS: Windows 2000

Problem description:
I have two files, 1 assembly file (CRT0.S) and 1 c file (MAIN.C).
Assembly file is compiled with: h8300-elf-as crt0.s -o crt0.o
Source file is compiled with: h8300-elf-gcc -c -mh -O0 main.c
Linking is done with: h8300-elf-ld --oformat=srec -T h8300h.scr -Map
mapfile.txt

The assembly file contains two jumps, a long reconcode (0x29a7e520) and
some initialisation.

When checking the s-record output of the linker, the addresses of the
jumps are converted into 32bits (wrong) instead of 24-bits (correct).
This results into the problem that the second JMP command (5A) is gone
because the first JMP address overlaps. Also the reconcode is corrupt
(became 0x4CA7E520 instead of 0x29a7e520) where the 4C is the last byte
of the previous jump address.

The workaround is to generate a general output format (elf32-h8300) from
the linker (no s-record) and then use the following command to create a
s-record output file: h8300-elf-objcopy -O srec applic.a37

I have included my project files with makeall.bat files to create the
output.
Folder “NOK” contains the incorrect result, folder “OK” the correct
result.

Here the difference between the first lines of the output files
<applic.a37>:
[NOK] S11300005A000000100000004CA7E5200000020088
              ^^
              JMP
 [OK] S11300005A0000105A00004C29A7E5200000020005
              ^^      ^^      ^^^^^^^^
              JMP     JMP     reconcode            

The attachment is a .zip file.

Please inform me whether the bug is a known bug, if it will be fixed and
if there are any other workarounds.


Thank you in advance,
 
Nico Langenberg
Embedded Software Engineer

IOLAN B.V., Mon Plaisir 26, 4879 AN Etten-Leur, The Netherlands
Tel.: +31 (0)76 50 38 236, Fax.: +31 (0)76 50 38 719
E-mail:address@hidden
Homepage: http://www.iolan.com

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de
afzender direct te informeren door het bericht te retourneren.
The information contained in this message may be confidential and is
intended to be exclusively for the addressee. Should you receive this
message unintentionally, please do not use the contents here in and
notify the sender immediately by return e-mail.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]