On 2017-Jan-20, at 3:19 PM, Mark Millard wrote:
> FYI: The code that is put in the .plt that does not
> match the .got.plt layout used (expecting function
> descriptors when there are only single addresses per
> function as a .got.plt entry) is:
>
> void PPC64TargetInfo::writePlt(uint8_t *Buf, u
FYI: The code that is put in the .plt that does not
match the .got.plt layout used (expecting function
descriptors when there are only single addresses per
function as a .got.plt entry) is:
void PPC64TargetInfo::writePlt(uint8_t *Buf, uint64_t GotEntryAddr,
uint64_t
I did a bunch more investigation and have 4 major points
that I think I've established:
First off: I've still not found a single example
of a document's coverage of powerpc64 (or powerpc) that
deals with the .got vs. .got.plt split [.got in RELRO region
but .got.plt possibly not (lazy relocation t
On 2017-Jan-19, at 12:05 PM, Roman Divacky wrote:
> Type = 38 should be R_ABS so thats fine. If what I expected to be in .got
> is in .got.plt, what happens if you modify the getPPC64TocBase() to
> use ::GotPlt instead of ::Got ?
For using GotPlt. . .
-pie use still gets the notices:
can't cre
Type = 38 should be R_ABS so thats fine. If what I expected to be in .got
is in .got.plt, what happens if you modify the getPPC64TocBase() to
use ::GotPlt instead of ::Got ?
On Thu, Jan 19, 2017 at 01:46:02AM -0800, Mark Millard wrote:
> I should have noted that -pie gets the same sort of
> reado
I should have noted that -pie gets the same sort of
readonly segment errors as -shared did:
# clang -fuse-ld=lld -g -pie empty_src.c
Type = 50
Type = 64
Type = 50
Type = 64
Type = 50
Type = 64
Type = 50
Type = 64
Type = 50
Type = 64
Type = 10
Type = 10
Type = 50
Type = 64
Type = 50
Type = 48
Type
The log messages code does not work because of Assertion failures:
# clang -fuse-ld=lld -g main.c
Type = 50, name = Assertion failed: (!isLocal()), function getName, file
/usr/src/contrib/llvm/tools/lld/ELF/Symbols.cpp, line 100.
clang: error: unable to execute command: Abort trap (core dumped)
c
Well trying to have the global variable in various forms produced
more information when I tried having it in a shared object:
(This was before your changes to add log messages.)
# more gblvar.c
volatile long gblvar = 1;
# clang -g -fuse-ld=lld -shared -o gblvar.so gblvar.c
can't create dynamic re
On 2017-Jan-18, at 1:54 PM, Roman Divacky wrote:
> I think I got it all wrong. I think what lld is trying to achieve
> is to have the PLT entry to jump to GOT which references the real symbol.
>From what I've read: for code references the .got.plt section would
be involved when it exists, not th
I think I got it all wrong. I think what lld is trying to achieve
is to have the PLT entry to jump to GOT which references the real symbol.
For some reason, GOT is empty, in our case. I believe this might be caused
by a relocation thats wrongly mapped to R_ABS in PPC64TargetInfo::getRelExpr().
Ma
Using the new changed line (Plt use now):
uint64_t TocVA = Out::Plt->getVA();
changed the behavior and it gets farther for
-fuse-ld=lld based linking. But it is r2 leading
to r3 content that is dereferenced and 8(r3) fails
this time. This was in the process of finding
the new r2 value for the fol
Go with Out.
On Tue, Jan 17, 2017 at 01:53:14PM -0800, Mark Millard wrote:
> On 2017-Jan-17, at 11:54 AM, Roman Divacky wrote:
>
> . . .
> > I wonder if it doesnt work because of my first patch (the one to turn GOT
> > reloc into PLT one).
> >
> > LLD understands that we use GOT as TOC (which w
On 2017-Jan-17, at 11:54 AM, Roman Divacky wrote:
. . .
> I wonder if it doesnt work because of my first patch (the one to turn GOT
> reloc into PLT one).
>
> LLD understands that we use GOT as TOC (which was true before my patch),
> I wonder if something like this:
>
> ndex: tools/lld/ELF/Targ
Mark,
I wonder if it doesnt work because of my first patch (the one to turn GOT
reloc into PLT one).
LLD understands that we use GOT as TOC (which was true before my patch),
I wonder if something like this:
ndex: tools/lld/ELF/Target.cpp
==
I found some wording relating older-style .got to newer style .got/.got.plt
pair of sections (that need not be near each other). . .
https://sourceware.org/ml/binutils/2004-03/msg00350.html
says that the .got has been split in two: in essence the RELRO part
and the non-RELRO part. Quoting:
> .go
[Correcting a poor wording/interpetatation.]
On 2017-Jan-16, at 3:28 PM, Mark Millard wrote:
> Looking up definitions of the section naming
> (using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . .
> (Intel context)
>
>
> It looks like the RELRO segment (program header information) requ
Looking up definitions of the section naming
(using http://www.cs.stevens.edu/~jschauma/810/elf.html ). . .
(Intel context)
It looks like the RELRO segment (program header information) requires
the .got section to be with the .ctors, .dtros, .jcr and such sections:
.got is supposed to be inside t
Here is a more direct list of section addresse rangess from gdb
for ld.lld output:
(I've added comments on the right.)
(gdb) info file
Symbols from "/root/c_tests/a.out".
Local exec file:
`/root/c_tests/a.out', file type elf64-powerpc-freebsd.
Entry point: 0x100300a0
0x
On 2017-Jan-16, at 11:40 AM, Roman Divacky wrote:
> I think the TOC (.got + .plt) has to be contiguous in memory. The on-disk
> layout is not that important.
I showed the address column that I would expect to accurately reflect addresses
to load to in the process. I also showed the Offset Align
Mark,
I think the TOC (.got + .plt) has to be contiguous in memory. The on-disk
layout is not that important.
Can you check whats the difference of the in-memory TOC between lld and ld.bfd?
Thanks, Roman
On Fri, Jan 13, 2017 at 02:07:00PM -0800, Mark Millard wrote:
> Just an FYI:
>
> elfdump -
Just an FYI:
elfdump -a (from -r311950) does not dump .plt or .got.plt or .toc :
# elfdump -a a.out | egrep "(got|toc|plt|:$)" | more
elf header:
program header:
section header:
sh_name: .rela.plt
sh_name: .plt
sh_name: .got
sh_name: .got.plt
sh_name: .toc
On 2017-Jan-12, at 11:22 AM, Roman Divacky wrote:
> Can you check if the TOC is correct? LLD assumes this:
>
> static uint64_t PPC64TocOffset = 0x8000;
>
> uint64_t getPPC64TocBase() {
> // The TOC consists of sections .got, .toc, .tocbss, .plt in that order. The
> // TOC starts where the fir
Can you check if the TOC is correct? LLD assumes this:
static uint64_t PPC64TocOffset = 0x8000;
uint64_t getPPC64TocBase() {
// The TOC consists of sections .got, .toc, .tocbss, .plt in that order. The
// TOC starts where the first of these sections starts. We always create a
// .got when w
On 2017-Jan-11, at 1:23 PM, Ed Maste wrote:
> On 11 January 2017 at 21:06, Roman Divacky wrote:
>> Looks like a progress :) Three questions...
>>
>> Is the readelf -a reasonable now?
>
> FYI, I just committed an ELF Tool Chain fix (r311941) so readelf
> should display the relocation types prop
On 11 January 2017 at 21:06, Roman Divacky wrote:
> Looks like a progress :) Three questions...
>
> Is the readelf -a reasonable now?
FYI, I just committed an ELF Tool Chain fix (r311941) so readelf
should display the relocation types properly now.
> If you compile with -g, does the
> backtrace
Looks like a progress :) Three questions...
Is the readelf -a reasonable now? If you compile with -g, does the
backtrace make a bit more sense? And finally, can you try to "nexti/stepi" in
gdb from
_start to see where things go wrong? Possibly doing it both for ld linked a.out
and lld linked a.ou
On 2017-Jan-11, at 11:48 AM, Roman Divacky wrote:
> Can you try this patch?
>
> Index: tools/lld/ELF/Target.cpp
> ===
> --- tools/lld/ELF/Target.cpp (revision 291691)
> +++ tools/lld/ELF/Target.cpp (working copy)
> @@ -1062,7 +106
Can you try this patch?
Index: tools/lld/ELF/Target.cpp
===
--- tools/lld/ELF/Target.cpp(revision 291691)
+++ tools/lld/ELF/Target.cpp(working copy)
@@ -1062,7 +1062,8 @@
}
PPC64TargetInfo::PPC64TargetInfo() {
- PltRel =
On 2017-Jan-11, at 8:07 AM, Ed Maste wrote:
> On 11 January 2017 at 04:15, Mark Millard wrote:
>>
>> # ./a.out
>> ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374
>> Abort trap (core dumped)
>
> Would you paste the output of `readelf -r a.out`?
Here you go, for ld.
On 11 January 2017 at 04:15, Mark Millard wrote:
>
> # ./a.out
> ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/powerpc64/reloc.c:374
> Abort trap (core dumped)
Would you paste the output of `readelf -r a.out`?
___
freebsd-toolchain@freebsd.org m
[Note that the /usr/bin/ld.lld here was built via buildworld
on the powerpc64 machine: native build, not a cross build.]
Roman Divacky had suggested:
From: Roman Divacky
Date: January 8, 2017 at 6:41:33 AM PST
> Would you be interested in trying lld? It has some support for ppc/ppc64,
> which
31 matches
Mail list logo
