On 2020-01-04, Fangrui Song wrote:
-fpatchable-function-entry is used by Linux kernel arm64/parisc. The
feature works for x86, but does not leverage multi-byte NOP.
% cat a.c
int foo() { return 0; }
% gcc -fpatchable-function-entry=5,0 -c a.c
% objdump -d a.o
...
:
0: 90
On 1/4/20 9:48 PM, Fangrui Song wrote:
-fpatchable-function-entry is used by Linux kernel arm64/parisc. The
feature works for x86, but does not leverage multi-byte NOP.
% cat a.c
int foo() { return 0; }
% gcc -fpatchable-function-entry=5,0 -c a.c
% objdump -d a.o
...
:
0:
On Mon, 6 Jan 2020, Martin Liška wrote:
> You are right, we do not leverage multi-byte NOPs. Note that the support
> depends
> on a CPU model (-march) and the similar code is quite complex in binutils:
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-i386.c;h=d0b8f
On Mon, 6 Jan 2020 at 06:57, Yu <17671260...@163.com> wrote:
>
> Hello,
>
> I have some questions about developing my own compiler plugin. I tried to
> develop it using
> riscv-gnu-toolchain(https://github.com/riscv/riscv-gnu-toolchain), but it
> couldn't find following header files.
Which head
+GCC
On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
>
> In an archive test rebuild with binutils and GCC trunk, I see a lot of build
> failures on both aarch64-linux-gnu and arm-linux-gnueabihf failing with
> "multiple definition of symbols" when linking executables, e.g.
THIS IS NOT A BIN
On 06.01.20 11:03, Andrew Pinski wrote:
> +GCC
>
> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
>>
>> In an archive test rebuild with binutils and GCC trunk, I see a lot of build
>> failures on both aarch64-linux-gnu and arm-linux-gnueabihf failing with
>> "multiple definition of symbols"
On Fri, 3 Jan 2020 at 16:09, Erick Ochoa wrote:
> Do you mean something like taking the address of a struct and adding an offset
> to access a field?
Yes, the following code is valid:
struct S { int unused; int used; };
static_assert( sizeof(S) == 8 );
S s[4];
int* s2_used = (int*)((char*)s + 20)
On 06.01.20 11:03, Andrew Pinski wrote:
> +GCC
>
> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
>>
>> In an archive test rebuild with binutils and GCC trunk, I see a lot of build
>> failures on both aarch64-linux-gnu and arm-linux-gnueabihf failing with
>> "multiple definition of symbols"
On 06.01.20 13:30, Wilco Dijkstra wrote:
> On 06.01.20 11:03, Andrew Pinski wrote:
>> +GCC
>>
>> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
>>>
>>> In an archive test rebuild with binutils and GCC trunk, I see a lot of build
>>> failures on both aarch64-linux-gnu and arm-linux-gnueabihf
On 06.01.20 14:29, Matthias Klose wrote:
> On 06.01.20 13:30, Wilco Dijkstra wrote:
>> On 06.01.20 11:03, Andrew Pinski wrote:
>>> +GCC
>>>
>>> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
In an archive test rebuild with binutils and GCC trunk, I see a lot of
build
fai
On 1/6/20 2:29 PM, Matthias Klose wrote:
On 06.01.20 13:30, Wilco Dijkstra wrote:
On 06.01.20 11:03, Andrew Pinski wrote:
+GCC
On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
In an archive test rebuild with binutils and GCC trunk, I see a lot of build
failures on both aarch64-linux-gnu
On Mon, Jan 6, 2020 at 5:29 AM Matthias Klose wrote:
>
> On 06.01.20 13:30, Wilco Dijkstra wrote:
> > On 06.01.20 11:03, Andrew Pinski wrote:
> >> +GCC
> >>
> >> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
> >>>
> >>> In an archive test rebuild with binutils and GCC trunk, I see a lot of
Hi,
> However, this is an undocumented change in the current NEWS, and seeing
>> literally hundreds of package failures, I doubt that's the right thing to
>> do, at
>> least without any deprecation warning first. Could that be handled,
>> deprecating
>> in GCC 10 first, and the changing t
On Mon, Jan 6, 2020 at 6:02 AM Wilco Dijkstra wrote:
>
>
> Hi,
>
> > However, this is an undocumented change in the current NEWS, and seeing
> >> literally hundreds of package failures, I doubt that's the right thing to
> >> do, at
> >> least without any deprecation warning first. Could that be
On Mon, 6 Jan 2020 at 13:37, Martin Liška wrote:
>
> On 1/6/20 2:29 PM, Matthias Klose wrote:
> > On 06.01.20 13:30, Wilco Dijkstra wrote:
> >> On 06.01.20 11:03, Andrew Pinski wrote:
> >>> +GCC
> >>>
> >>> On Mon, Jan 6, 2020 at 1:52 AM Matthias Klose wrote:
>
> In an archive test rebu
On 06.01.20 15:02, Wilco Dijkstra wrote:
>> However, this is an undocumented change in the current NEWS, and seeing
>>> literally hundreds of package failures, I doubt that's the right thing to
>>> do, at
>>> least without any deprecation warning first. Could that be handled,
>>> deprecating
>>>
On Fri, 3 Jan 2020, Joseph Myers wrote:
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7a.git
> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-7b.git
I have not had a substantial commit to gcc [or, likely, post to this
list] in a decade THUS a warm howdy to anyone still around from
19
On Fri, Jan 3, 2020 at 4:38 AM Joseph Myers wrote:
>
> On Sat, 28 Dec 2019, Joseph Myers wrote:
>
> > Two more.
> >
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
> > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6b.git
>
> Two more.
>
> git+ssh://gcc.gnu.org/home/gccadmin/gc
On Mon, 6 Jan 2020, Andrew Pinski wrote:
> ** Also I Noticed the author for that revision is detected as
> pins...@gcc.gnu.org but that is because I used different cases for the
> emails in the changelog.
In my review of possibly suspect authors I'm concentrating on cases where
the author name n
On 06/01/2020 23:57, Andrew Pinski wrote:
> On Fri, Jan 3, 2020 at 4:38 AM Joseph Myers wrote:
>>
>> On Sat, 28 Dec 2019, Joseph Myers wrote:
>>
>>> Two more.
>>>
>>> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6a.git
>>> git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-6b.git
>>
>> Two
The addresses of NOPs are collected in a section named
__patchable_function_entries.
A __patchable_function_entries entry is relocated by a symbolic relocation
(e.g. R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64).
In -shared or -pie mode, the linker will create a dynamic relocation
(non-preempti
On 2020-01-06, Fangrui Song wrote:
The addresses of NOPs are collected in a section named
__patchable_function_entries.
A __patchable_function_entries entry is relocated by a symbolic relocation
(e.g. R_X86_64_64, R_AARCH64_ABS64, R_PPC64_ADDR64).
In -shared or -pie mode, the linker will create
22 matches
Mail list logo
