[Top][All Lists]
[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.
- Bug found when linking to S-RECORD type,
Nico Langenberg <=