https://sourceware.org/bugzilla/show_bug.cgi?id=29655
--- Comment #24 from Rui Ueyama ---
Any updates on this? It looks like this is still broken with GCC15
(https://github.com/rui314/mold/pull/1406). This can cause very subtle but
hard-to-debug compatibility issues for s390x, so it needs to be a
https://sourceware.org/bugzilla/show_bug.cgi?id=30033
Rui Ueyama changed:
What|Removed |Added
CC||rui314 at gmail dot com
--- Comment #5
https://sourceware.org/bugzilla/show_bug.cgi?id=30612
Rui Ueyama changed:
What|Removed |Added
CC||rui314 at gmail dot com
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #21 from Rui Ueyama ---
How about splitting the .got section into two, one is for the first three words
and the other for the rest of .got and then place the first one in a relro
segment? It would be much easier to do than carefull
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #18 from Rui Ueyama ---
> > IOW, an additional LOAD program-header. I too have thought of that.
>
> It doesn’t need an additional program header. Relro sections are just at the
> end of the RW segment as you can see in my example
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #17 from Rui Ueyama ---
> IOW, an additional LOAD program-header. I too have thought of that.
It doesn’t need an additional program header. Relro sections are just at the
end of the RW segment as you can see in my example.
--
Y
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #14 from Rui Ueyama ---
> I like this, thanks! (psykose/alice confirmed lld does not have the problem
> on alpine, but I am not sure if they do the correct thing™ here security-wise
> -- it's good to have a concrete idea here)
Y
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
--- Comment #12 from Rui Ueyama ---
In the mold linker, we are dealing with the issue by mapping the page that is
at the boundary of relro and non-relro twice as the last relro page and the
first non-relro page. Here is an example of the mold-
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: rui314 at gmail dot com
Target Milestone: ---
readelf doesn't pretty print symbol type of STT_GNU_IFUNC unless ELF header's
EI_OSABI is set to ELFOSA
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 #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 #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 #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 #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 #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 #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 #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
: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: rui314 at gmail dot com
Target Milestone: ---
gas 2.38 assembles the following assembly
larl %r1,printf
brasl %r1,printf
into the following object file
https://sourceware.org/bugzilla/show_bug.cgi?id=29639
--- Comment #3 from Rui Ueyama ---
Oh, I didn't know that that change has been made. Thank you for your quick
response! I'm closing this issue as a duplicate.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=29639
Rui Ueyama changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://sourceware.org/bugzilla/show_bug.cgi?id=28824
Rui Ueyama changed:
What|Removed |Added
CC||rui314 at gmail dot com
--- Comment #9
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rui314 at gmail dot com
Target Milestone: ---
Currently, the default value of `-z max-page-size` and `-z common-page-size`
are 65536 and 4096 on ARM64, respectively. That means an executable created by
GNU ld
https://sourceware.org/bugzilla/show_bug.cgi?id=29557
Rui Ueyama changed:
What|Removed |Added
CC||rui314 at gmail dot com
--- Comment #1
https://sourceware.org/bugzilla/show_bug.cgi?id=29072
--- Comment #3 from Rui Ueyama ---
Right. Unless you know the default behavior of GNU ld, it is very hard to
foresee that adding a benign assembler file to your project could make it
significantly vulnerable to the traditional stack overflow a
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: rui314 at gmail dot com
Target Milestone: ---
GCC's nested function
(https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html) depends on the
execu
25 matches
Mail list logo
