https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #3 from Martin Liska ---
Feel free to create a GCC bug for it, thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at linux dot ibm.com
--- Co
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #5 from Rui Ueyama ---
Ooh, that's why I did see this only on SuSE's builder. I'm glad that that's
already been handled.
mold does not create PLT for R_390_PC32DBL; it does only for R_390_PLT* relocs.
We can change that so that mo
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #6 from Andreas Krebbel ---
(In reply to Rui Ueyama from comment #5)
> Ooh, that's why I did see this only on SuSE's builder. I'm glad that that's
> already been handled.
I would just like to mention that adding the @PLT isn't rea
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #7 from Rui Ueyama ---
It's about pointer equality. C/C++ guarantees that two function pointers are
equal if and only if they are for the same function. For example, an expression
`&printf` in your main program code should yields t
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #8 from Ulrich Weigand ---
(In reply to Rui Ueyama from comment #7)
> A main executable's PLT entry that is used as a function address is often
> called a "canonical PLT".
>
> If the main executable isn't compiled as PIC, and if i
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #9 from Rui Ueyama ---
> My understanding is that the canonical function address of `foo` is the
> address of the PLT for `foo` in the main executable, *if such a PLT
> exists*, and the address of `foo` otherwise. That PLT exists
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #10 from Ulrich Weigand ---
(In reply to Rui Ueyama from comment #9)
> However, the PLT address is not used as its function address as you can see
> below.
>
> $ ./test1
> foo=0x7f60482d3110 bar=0x7f60482d3120
Well, when I r
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #11 from Rui Ueyama ---
> Well, when I run your example (exact same commands on s390x), I get:
>
> ./test1
> foo=0x3ff89800620 bar=0x10004d8
>
> (That's the default toolchain on Ubuntu 20.04)
Yes, that's the compatibility issue
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #12 from Andreas Krebbel ---
So do I understand it correctly that for the Qt case the example would look
more like this:
test2.c:
#include
void alias () __attribute__ ((weak, alias ("bar")));
void bar() { printf("bar=%p alias=%
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #13 from Ulrich Weigand ---
In any case, I still don't quite get where there is any incompatibility.
If `bar` resolves to its canonical PLT address, and you use `--defsym=foo=bar`,
then `foo` will *also* resolve to the canonical P
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #15 from Ulrich Weigand ---
Thanks for the test case! A few comments:
1. In this scenario, it is indeed not guaranteed that fn1 compares equal to
fn1_public everywhere. This is because fn1 is declared hidden in libfoo.c, so
all
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #14 from Rui Ueyama ---
The following bash script should demonstrate the issue better:
-
cat < libfoo.h
#ifndef __PIC__
#error "this file must be compiled with -fPIC"
#endif
typedef void Fn();
void fn1_public(void);
void call
https://sourceware.org/bugzilla/show_bug.cgi?id=29660
Bug ID: 29660
Summary: Duplicated symbols count twice for linker script
sections?
Product: binutils
Version: 2.33
Status: UNCONFIRMED
Severity: normal
https://sourceware.org/bugzilla/show_bug.cgi?id=29660
Alan Modra changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
15 matches
Mail list logo
