https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #23 from Ilya Leoshkevich ---
I'm currently regtesting the attached patch.
This discussion made me realize that our hotpatching support is currently
broken in a fashion similar to that of Qt5 (details in the patch's commit
message
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comme
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #21 from Andreas Krebbel ---
(In reply to Rui Ueyama from comment #20)
> GCC 12 seems to always append `@PLT` to a function symbol even if we are not
> calling that function. Here is a test case.
...
> I think `larl %r1,foo@PLT` sh
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #20 from Rui Ueyama ---
GCC 12 seems to always append `@PLT` to a function symbol even if we are not
calling that function. Here is a test case.
```
$ echo 'void foo(); void *bar() { return foo; }' | gcc-12 -S -o- -xc -
.f
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #19 from Andreas Krebbel ---
(In reply to Rui Ueyama from comment #18)
> Was there any reason to limit it to R_390_64 and R_390_PC32DBL?
These were the only relocs which made sense to me as 64 bit pointers.
--
You are receiving
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #18 from Rui Ueyama ---
Was there any reason to limit it to R_390_64 and R_390_PC32DBL?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #17 from Andreas Krebbel ---
I have attached a patch for the testcase in Comment 14. Turns out that we also
have to zero out the symbol value in order to avoid function pointer references
in the main binary to be wired up to the ma
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #16 from Andreas Krebbel ---
Created attachment 14386
--> https://sourceware.org/bugzilla/attachment.cgi?id=14386&action=edit
Experimental Fix
This patch fixes the testcase from comment 14. No testsuite regressions in the
Binuti
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=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 #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 #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 #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 #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 #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 #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 #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 #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 #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
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at linux dot ibm.com
--- Co
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
--- Comment #2 from Rui Ueyama ---
Then it's a GCC's bug that doesn't generate R_390_PC32PLT for `brasl` for
-fno-PIC. Again, this is subtle, but can cause a real issue. I don't think you
can build working Qt5 apps with the current gcc/gas out
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
Ulrich Weigand changed:
What|Removed |Added
CC||uweigand at gcc dot gnu.org
--- Comm
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
Martin Liska changed:
What|Removed |Added
CC||mliska at suse dot cz
--
You are rece
https://sourceware.org/bugzilla/show_bug.cgi?id=29655
David Edelsohn changed:
What|Removed |Added
Target||s390x-*-linux-gnu
CC
25 matches
Mail list logo
