On Thu, Jul 4, 2024 at 12:42 PM Fangrui Song wrote:
>
> I have noticed that Meta Platforms folks have a proposal to extend the
> .loc directive
> https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608
> .
> I filed https://sourc
I have noticed that Meta Platforms folks have a proposal to extend the
.loc directive
https://discourse.llvm.org/t/rfc-extending-llvm-mc-loc-directive-with-labeling-support/79608
.
I filed https://sourceware.org/bugzilla/show_bug.cgi?id=31955 ("gas:
Extend .loc directive to emit a label") and am
On Thu, May 2, 2024 at 8:35 AM Pedro Alves wrote:
>
> On 2024-05-01 22:04, Simon Marchi wrote:
> > The Change-Id trailer works very well for Gerrit: once you have the hook
> > installed you basically never have to think about it again, and Gerrit
> > is able to track patch versions perfectly accur
On Thu, Mar 28, 2024 at 2:23 AM Jan Beulich wrote:
>
> On 28.03.2024 08:43, Fangrui Song wrote:
> > On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote:
> >>
> >> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> >>>
> >>> The relocat
On Thu, Mar 28, 2024 at 6:04 AM Alan Modra wrote:
>
> On Fri, Mar 22, 2024 at 06:51:41PM -0700, Fangrui Song wrote:
> > On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> > > I propose RELLEB, a new format offering significant file size
> > > reductions: 17.2%
On Fri, Mar 22, 2024 at 6:51 PM Fangrui Song wrote:
>
> On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
> >
> > The relocation formats REL and RELA for ELF are inefficient. In a
> > release build of Clang for x86-64, .rela.* sections consume a
> > significant po
On Thu, Mar 14, 2024 at 5:16 PM Fangrui Song wrote:
>
> The relocation formats REL and RELA for ELF are inefficient. In a
> release build of Clang for x86-64, .rela.* sections consume a
> significant portion (approximately 20.9%) of the file size.
>
> I propose RELLEB, a n
The relocation formats REL and RELA for ELF are inefficient. In a
release build of Clang for x86-64, .rela.* sections consume a
significant portion (approximately 20.9%) of the file size.
I propose RELLEB, a new format offering significant file size
reductions: 17.2% (x86-64), 16.5% (aarch64), and
On Thu, Jan 18, 2024 at 5:42 PM LIU Hao wrote:
>
> 在 2024-01-18 17:02, Fangrui Song 写道:
> > Thanks for the proposal. I hope that -masm=intel becomes more useful:)
> >
> > Do you have a list of assembly in the unambiguous cases that fail to
> > be parsed today as a ga
On Wed, Jan 17, 2024 at 9:34 PM LIU Hao wrote:
>
> Hello,
>
> There hasn't been an solution to https://gcc.gnu.org/PR53929 since almost a
> dozen years ago, mostly
> due to compatibility with MASM. I was told that the ambiguity of Intel syntax
> should be classified
> as its own limitation and d
I created https://groups.google.com/g/generic-abi/c/satyPkuMisk ("Add new
ch_type value: ELFCOMPRESS_ZSTD") after I saw that on LLVM side, Cole Kissane
proposes that we add Zstandard as new compression method (mainly for .debug*
sections, but also for some LLVM internal things)
https://discourse.l
On 2021-06-18, H.J. Lu via llvm-dev wrote:
Add GNU_PROPERTY_1_NEEDED:
#define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO
to indicate the needed properties by the object file.
I am fine with this logical OR style usage. But see below, do we need it
for ld.so runtime check?
(As I me
On 2021-06-17, H.J. Lu via llvm-dev wrote:
On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote:
On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
>
> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
>
> #define GNU_PROPERTY_UINT32_AND_LO 0xb000
> #define GNU_PROPERTY_UINT32_AND_HI 0xb00
Hi, elves (people who work on ELF)!
Motivated by a recent rant from Linus Torvalds on shared objects' performance
issues and a previous post about CPython 1.3x speedup with
-fno-semantic-interposition 1.3x, I have thought about an ELF world with
STB_GLOBAL variant of -Bsymbolic-functions by defau
On 2021-04-17, H.J. Lu wrote:
On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song wrote:
On 2021-01-21, H.J. Lu via Gnu-gabi wrote:
>On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
>>
>> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
>>
>> #define GNU_PROPER
On 2021-01-21, H.J. Lu via Gnu-gabi wrote:
On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrote:
1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI
#define GNU_PROPERTY_UINT32_AND_LO 0xb000
#define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff
A bit in the output pr_data field is set only if i
On Thu, Jan 7, 2021 at 6:07 PM H.J. Lu wrote:
>
> On Wed, Jan 6, 2021 at 10:32 PM Fangrui Song wrote:
> >
> > On Sat, Dec 26, 2020 at 7:39 AM H.J. Lu wrote:
> > >
> > > On Sat, Dec 26, 2020 at 7:32 AM Florian Weimer wrote:
> > > >
> > &
On Sat, Dec 26, 2020 at 7:39 AM H.J. Lu wrote:
>
> On Sat, Dec 26, 2020 at 7:32 AM Florian Weimer wrote:
> >
> > * Fangrui Song:
> >
> > > Hi, I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 which
> > > proposes -fdirect-access-external-data
Hi, I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 which
proposes -fdirect-access-external-data to address some x86-64
GCC/binutils pain[1] and also benefit non-x86 architectures (also see [1]
it can prevent copy relocations).
[1] Mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi
Fix email addresses:)
On 2020-07-09, Fangrui Song wrote:
Both GCC and Clang have implemented many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
A non-complete list of GCC supported debug options is documented here at
https
Both GCC and Clang have implemented many debugging options under -f and
-g. Whether options go to -f or -g appears to be pretty arbitrary decisions.
A non-complete list of GCC supported debug options is documented here at
https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
I think there op
On 2020-03-24, H.J. Lu via Binutils wrote:
On Tue, Mar 24, 2020 at 11:02 AM Gunther Nikl wrote:
Dear GCC developers!
I just noticed that the server migration for GCC and sourceware.org
brought a surprising change: The list archives are now provided with
mailman. Maybe its only me, but IMO w
GCC never evaluates __atomic_is_lock_free to 0.
(gcc/builtins.c:fold_builtin_atomic_always_lock_free)
I'd like to change clang to eagerly evaluate __atomic_is_lock_free to 0 for
apparently oversized types.
This helps some platforms to avoid a dependency on libatomic.
Either of the following cho
On 2020-01-09, Fangrui Song wrote:
On 2020-01-08, Fangrui Song wrote:
On 2020-01-07, Szabolcs Nagy wrote:
On 07/01/2020 07:25, Fangrui Song wrote:
On 2020-01-06, Fangrui Song wrote:
The addresses of NOPs are collected in a section named
__patchable_function_entries.
A
On 2020-01-08, Fangrui Song wrote:
On 2020-01-07, Szabolcs Nagy wrote:
On 07/01/2020 07:25, Fangrui Song wrote:
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
On 2020-01-07, Szabolcs Nagy wrote:
On 07/01/2020 07:25, Fangrui Song wrote:
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
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
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-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
-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 nop
1: 90
On x86-64, in PIE mode, accesses to external data don't use the conservative
GOT-relative address, but rather use pcrel. A copy relocation will be created
if the external data is defined in a DSO.
// a.o
// (x) GCC<5, movq a@GOTPCREL(%rip), %rax; movl (%rax), %eax
// (y) GCC>=5 (since commit 13
31 matches
Mail list logo
