uClinux-H8

Fork

• uClinux-dist
• elf2flt
• linux
• uClibc
• uclibc-ng

RX update

RX relocation fix

RX support

From: Larry Baker <baker@usgs.gov>

The _stack_start symbol needs to be in the same flatmem memory region
as text/data/bss, otherwise it will not end up with the correct address.
Direct the section into the flatmem region.

Signed-of-by: Greg Ungerer <gerg@uclinux.org>

The GNU linker uses -v as a shortcut to --version, not --verbose. So atm,
if you run `ld -v` to get the linker version, ld-elf2flt throws out a lot
of verbose debugging information. So drop the -v checking in ld-elf2flt
to keep from breaking systems that parse the linker version.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

the attached patch is needed for the recent elf2flt
on MinGW builds. The stat() cannot cope with directories
ending with the directory separator.

Regards
Stanislav Meduna <stano@meduna.org>

The .note.ABI-tag section exists to indicate to other projects (like gdb
or library loaders) information about the target OS. It doesn't actually
contain anything that is used at runtime. So while the current linker
script gathers this into the .data section, the final FLAT doesn't include
anything from it. But tools expect to find a dedicated section in ELFs
which the current section merge prevents.^M

So give .note.ABI-tag its own output section so gdb can locate and use it.
This shouldn't change the FLAT files produced in any way.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

When we converted ld-elf2flt from the shell script to C, one small nuance
was missed: argv[0] contains the full path only when invoked with the full
path. This is not the same behavior for shell scripts as $0 is always the
full path to the script in question. Most of the time this isn't an issue
as gcc will invoke all of its tools (like the linker) with a full relative
path to itself. However, if we attempt to invoke the linker directly, we
can see misbehavior such as:
bfin-uclinux-ld.real: cannot open linker script file ./../lib/elf2flt.ld:
No such file or directory

So, to fix this, we lean on more libiberty functions. Specifically, the
make_relative_prefix() function. This function locates a full argv[0] by
scanning $PATH to see where it was invoked. This might sound a little
dodgy, but this is fundamental to how gcc and binutils implement support
for their runtime relocation, so it can't break ld-elf2flt without first
breaking every one else ;).

In the fall out of this fix, we can cull a bunch of local code that does
custom path parsing. So not only do we get to fix an annoying bug, we get
to shrink code in the process.

Signed-off-by: Steve Kilbane <steve@whitecrow.demon.co.uk>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

The current code misses checking a few args in order to determine the
default "print" mode (ktrace/l1stack/...). Rather than update a list
that people easily forget, rework the code to generically detect that
no arguments have been specified.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

The sed debug showed incorrect syntax for deletions, and the program exec
debug missed output redirection.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Here is a patch to fix a ``misunderstanding'' between the kernel (bflt
loader) and GDB; noticed on m68k / coldfire uClinux.

Lacking specific directives in the linker script, the linker *may* decide
to put .text and .data into the same segment:

Section to Segment mapping:
Segment Sections...
00 .text .data .eh_frame_hdr .eh_frame .bss
01 .eh_frame_hdr

The bflt loader in the kernel will, however, add a small extra data table
just before .data's content (cf. handling of MAX_SHARED_LIBS in
binfmt_flat.c:load_flat_file).

Now, if .text and .data are in the same segment, directly following each
other in the binary file, but have that extra data table added in the
run-time memory layout, GDB will get very confused when trying to access
items in the now-moved .data section. Without any kernel (loader) / GDB
changes, the solution is to tell the linker to always put .text and .data
into separate segments, which GDB will handle gracefully then.

Section to Segment mapping:
Segment Sections...
00 .text
01 .data .eh_frame_hdr .eh_frame .bss

Tested on m68k-uclinux (where the problem occurred) and arm-uclinuxeabi
(no regressions).


2010-02-27 Thomas Schwinge <thomas@codesourcery.com>

use AS_HELP_STRING for all configure options
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

This is needed for Blackfin FLAT's to be processed properly, and apparently
some other people have seen similar behavior.

http://lists.uclibc.org/pipermail/uclibc/2009-April/042363.html
http://thread.gmane.org/gmane.linux.hardware.blackfin.toolchain.devel/1121

Signed-off-by: Bernd Schmidt <bernds_cb1@t-online.de>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Make varargs debug macros GCC-2.x compatible.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

[PATCH] add Blackfin to the README

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

fix option order when invoking children

Poor getopt() implementations as found in many BSD/Darwin systems will
stop processing options after a non-option is encountered. That means
ld-elf2flt has to be careful to not stick options after non-options when
executing sub children. In a default setup, it will invoke `elf2flt` with
the output followed by the -a option which subsequently fails:
elf2flt: Can't open '-a': No such file or directory

fix elf2flt dep generation in out-of-tree builds
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

the "all" target should not be depending on "ld-elf2flt"
anymore as this is handled through the PROG vars. it isnt a problem
for Linux systems, but when EXEEXT is set, things go boom.

Mike Frysinger <vapier.adi@gmail.com>

the Makefile.in still refers to elf2flt.sh.in:
ld-elf2flt.sh: $(srcdir)/ld-elf2flt.sh.in

that should be:
ld-elf2flt.sh: $(srcdir)/ld-elf2flt.in

the shell script is generated without +x bits, but that is fixed
during the install step ... so probably not a real big problem

Mike Frysinger <vapier.adi@gmail.com>

Due to shell portability issues (which is to say shell scripts are not
portable -- think Windows), convert elf2flt to C code.

I've updated this code base to the latest elf2flt tree and actually done
some basic tests -- building the three Blackfin tuples (ELF, FLAT, FDPIC)
and running programs on my Blackfin boards. This process found errors in
the original implementation as well as some of the cleanups I did.

Signed-off-by: Nathan Sidwell <nathan@codesourcery.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

handle more strip/verbose options.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Unify the duplicated windows and other system fallback logic in stubs.h
and add some fatal() helper functions to standardize the error output when
falling over. This way we don't end up with obscure error messages with
no idea what util they are coming from.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

generate dependency info automatically
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

This cleans up the Makefile handling of the different compiler flags such
that it uses standard names across the board as well as unifies the link
method.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

add more common files to gitignore
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

the flat.h header uses things like uint32_t but does not pull in the
appropriate stdint.h header

Mike Frysinger <vapier@gentoo.org>

We renamed all the Blackfin relocs in the toolchain to match other ports
(all caps and a R_BFIN_ prefix), so update elf2flt accordingly.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Rather than putting the `rm` at the end of the script before the normal
exit point, create a trap to automatically delete the script when exiting.
This way the linker script gets cleaned up whenever there is an error as
well. Otherwise every link invocation that ends in a failure could leave
behind crap. On my system, i found almost 2 million of these suckers in
my /tmp dir.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>

When the relocs are larger than 16bits, incorrect values are written when
the .H/.L loading are reversed. Normally this wouldn't happen because the
gcc compiler always outputs in the same order (first hi, then lo).

Signed-off-by: Jie Zhang <jie.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

Add -u/-U options to control the Blackfin L1 stack flag.

Signed-off-by: Bernd Schmidt <bernds_cb1@t-online.de>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>