• R/O
  • HTTP
  • SSH
  • HTTPS

elf2flt: List of commits


RSS
Rev. Time Author
d1f9afe rx 2015-06-09 16:29:55 Yoshinori Sato

RX update

03e2838 2015-06-09 16:29:19 Yoshinori Sato

RX relocation fix

78c97cf 2015-06-09 16:28:36 Yoshinori Sato

RX support

df29fce h8300 2015-06-09 16:25:17 Yoshinori Sato

R_H8_DIR24 fix

R_H8_DIR24A8 / R_H8_DIR24R8 keep all byte.

Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>

02cadeb 2015-06-09 16:11:04 Yoshinori Sato

H8/300 relocation fix

Add new relocation R_H8_DISP32A16.
hi-byte clear on R_H8_DIR32 R_H8_DIR24A8 R_H8_DIR24R8 R_H8_DIR32A16 R_H8_DISP32A16

Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>

ff674c2 2015-06-09 16:04:13 Yoshinori Sato

h8300 address space is 24bit.

Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>

5598aa5 2015-06-09 16:03:53 Yoshinori Sato

New bfd support

eb13e35 sh 2014-05-26 13:16:49 Yoshinori Sato

SH relocation fix

21c6a41 master 2012-10-04 11:32:38 Greg Ungerer

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>

e11cce2 2012-10-04 11:32:38 Greg Ungerer

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>

f999b84 2011-04-04 10:17:17 davidm


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>

40f0d17 2011-04-04 10:17:17 David McCullough


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>

69d8f60 2011-04-04 10:17:17 David McCullough


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>

df3ca30 2011-02-16 08:22:26 davidm


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>

17a6d6b 2011-02-16 08:22:26 David McCullough


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>

abce83b 2011-02-16 08:22:26 David McCullough


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>

00c7aa0 2010-12-16 10:37:41 davidm


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>

1ed805e 2010-12-16 10:37:41 David McCullough


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>

973b4b6 2010-12-16 10:37:41 David McCullough


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>

1101ea0 2010-08-17 13:25:26 davidm


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>

5b93746 2010-08-17 13:25:26 David McCullough


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>

6b3a08a 2010-08-17 13:25:26 David McCullough


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>

0a4959b 2010-06-22 15:12:47 davidm


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>

b3e607f 2010-06-22 15:12:47 David McCullough


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>

5839207 2010-06-22 15:12:47 David McCullough


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>

fa84942 2010-05-11 21:27:11 davidm


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

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

8a81e3b 2010-05-11 21:27:11 David McCullough


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

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

6317696 2010-05-11 21:27:11 David McCullough


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

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

4fab5b5 2010-03-09 15:19:11 gerg

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>

93d68ca 2010-03-09 15:19:11 Greg Ungerer

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>

Show on old repository browser