https://sourceware.org/bugzilla/show_bug.cgi?id=30844
Fangrui Song changed:
What|Removed |Added
CC||jnoorman at igalia dot com
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=30844
--- Comment #2 from Fangrui Song ---
(In reply to Palmer Dabbelt from comment #1)
> Nelson and I are just chatting about this. It's not intentional, but we
> also don't quite know what the right answer is here: there's some relocs we
> can to
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
https://sourceware.org/binutils/docs/ld/Output-Section-Fill.html
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h
ed conversion can all be described by existing
relocation types, which is nice.
However, I do not know whether the property will hold for all current and
future RISC-V relaxation schemes.
When investigating relocation overflow pressure for x86-64 small code model, I
have found that preserving the origina
https://sourceware.org/bugzilla/show_bug.cgi?id=30907
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Recently I have been dealing with a benign multiple definition related to
compiler-rt/lib/builtins and rust-lang/compiler-builtins.
I need
https://sourceware.org/bugzilla/show_bug.cgi?id=30865
--- Comment #5 from Fangrui Song ---
(In reply to Nick Clifton from comment #4)
> Created attachment 15115 [details]
> Proposed patch
Sorry for the late reply but the documentation and test change looks great!
There is a minor typo below
>
: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: yannik at sembritzki dot me
Target Milestone: ---
I am building a unified kernel image using objcopy. As this file is part of the
PCR event log which is used for
https://sourceware.org/bugzilla/show_bug.cgi?id=31077
--- Comment #1 from Yannik Sembritzki ---
This is most likely caused by some timestamp, as using
/usr/bin/faketime '2020-01-01' objcopy
results in a deterministic build.
--
You are receiving this mail because:
You are on the CC list for t
https://sourceware.org/bugzilla/show_bug.cgi?id=31077
Yannik Sembritzki changed:
What|Removed |Added
Summary|objcopy |objcopy has
|--
https://sourceware.org/bugzilla/show_bug.cgi?id=31077
--- Comment #3 from Yannik Sembritzki ---
Reading `man ar`, I now finally understand what `archive` means in this
context.
I didn't quite get that before, and thought it described the "archive" of
sections contained within the object file. Oop
https://sourceware.org/bugzilla/show_bug.cgi?id=31077
Yannik Sembritzki changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNC
||i at maskray dot me
Target Milestone|--- |2.41
Status|UNCONFIRMED |RESOLVED
--- Comment #8 from Fangrui Song ---
Implemented by
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
cat > a.s < a.t
echo 'PROVIDE(x = bar);' > b.t # not used, but worth testing
as a.s -o a.o
ld.lld --gc-sections a.o
https://sourceware.org/bugzilla/show_bug.cgi?id=31158
--- Comment #2 from Fangrui Song ---
Interesting. BFD's behavior depends on whether the assigned symbol is
referenced.
Let's enhance the test.
cat > a.s < a.t
as a.s -o a.o
ld.lld --gc-sections a.o a.t -o a.lld
ld.bfd --gc-sections a.o a.t -o
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: amy at amyspark dot me
Target Milestone: ---
Created attachment 15307
--> https://sourceware.org/bugzilla/attachment.cgi?id=15307&action=edit
https://sourceware.org/bugzilla/show_bug.cgi?id=31250
--- Comment #1 from Amyspark ---
7z compressed file of gstrswebrtc.lib:
https://s3.amyspark.me/temp/gstrswebrtc.7z
SHA256: de8d45f9a67b500c9f237375efca3593c2c301a7266b1ffd21b523dc35fc4b88
--
You are receiving this mail because:
You are on t
: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
objcopy supports --prefix-symbols to prefix all symbols.
Perhaps --prefix-symbols-remove= can be added to remove the prefix.
For example,
cat > a.s <https://github.co
https://sourceware.org/bugzilla/show_bug.cgi?id=31250
--- Comment #4 from Amyspark ---
Applied the patch on top of mingw-w64-binutils (commit
c2aee7d89488d9402315d59d25852dff258c9eba), and can confirm it works as
expected.
Only nit I could propose is to keep track of those files that have been
b
https://sourceware.org/bugzilla/show_bug.cgi?id=31250
--- Comment #5 from Amyspark ---
> Is the library really valid if it contains absolute pathnames ?
Yes, all that MSVC cares about is a) the symbol b) the path inside the .lib
pointing to an existing object. I was able to extract all of them
https://sourceware.org/bugzilla/show_bug.cgi?id=31250
--- Comment #8 from Amyspark ---
(In reply to Nick Clifton from comment #6)
>
> Actually that is a very interesting point. Does MSVC require that the path
> inside the lib point to an object that already exists or one that could
> exist, sho
https://sourceware.org/bugzilla/show_bug.cgi?id=31000
--- Comment #1 from Fangrui Song ---
On the llvm-objcopy side, someone proposes --set-symbol-visibility:
https://github.com/llvm/llvm-project/pull/80872
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=30788
Fangrui Song changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--
You are rec
https://sourceware.org/bugzilla/show_bug.cgi?id=31000
--- Comment #2 from Fangrui Song ---
(In reply to Fangrui Song from comment #1)
> On the llvm-objcopy side, someone proposes --set-symbol-visibility:
> https://github.com/llvm/llvm-project/pull/80872
The proposal looks like:
.. option:: --se
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Noticed while investigating the behavior of .rofixup
% cat a.s
.globl foo
foo:
bx lr
.data
.long foo
% ./bin
https://sourceware.org/bugzilla/show_bug.cgi?id=31407
Fangrui Song changed:
What|Removed |Added
Target||arm*-*-uclinuxfdpiceabi
https://sourceware.org/bugzilla/show_bug.cgi?id=31408
Fangrui Song changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
T
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
__attribute__((visibility("hidden"))) void fun_hidden();
void *fun_hidden_addr() { return
: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.s
.globl _start, f0, f1
.weak f2
.protected f1
_start: f0: f1: f2: fl: bx lr
.data
.long f0
https://sourceware.org/bugzilla/show_bug.cgi?id=31409
Fangrui Song changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--
You are r
https://sourceware.org/bugzilla/show_bug.cgi?id=31409
--- Comment #1 from Fangrui Song ---
bfd/elf32-arm.c:16521
if (eh->fdpic_cnts.funcdesc_cnt > 0)
{
if (htab->root.dynamic_sections_created && h->dynindx == -1
&& !h->forced_local)
if (! bfd_elf_link_record_dynamic
https://sourceware.org/bugzilla/show_bug.cgi?id=27452
--- Comment #2 from Fangrui Song ---
I find it very difficult to handle SHF_ALLOC sections due to data commands,
range extension thunks, and other features requiring fixed-point iteration.
Compressing non-SHF_ALLOC sections alone may yield a
: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
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
https://sourceware.org/bugzilla/show_bug.cgi?id=31475
Fangrui Song changed:
What|Removed |Added
Summary|binutils: Support RELLEB|binutils: Support CREL
https://sourceware.org/bugzilla/show_bug.cgi?id=31475
--- Comment #1 from Fangrui Song ---
The format was tentatively named RELLEB. As I refine the original pure
LEB-based format, “RELLEB” might not be the most fitting name.
I have switched to SHT_CREL/DT_CREL/.crel and updated
https://maskray.m
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
ELF defines two relocation formats, REL and RELA. REL uses implicit addends,
saving space compared to RELA's explicit addend field.
However, REL is often inadequat
https://sourceware.org/bugzilla/show_bug.cgi?id=27452
--- Comment #3 from Fangrui Song ---
The actual form I plan to use in lld is:
--compress-sections ={none,zlib,zstd}[:level]
zstd excels at scaling from low-ratio-very-fast to
high-ratio-pretty-slow. Some users prioritize speed and prefer dis
: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
An input section description file_pattern(section_pattern) couples two
operations:
* "defining": match a subset of sec
https://sourceware.org/bugzilla/show_bug.cgi?id=31688
Fangrui Song changed:
What|Removed |Added
Summary|ld: Add SECTION_CLASS to|ld: Add CLASS to allow
https://sourceware.org/bugzilla/show_bug.cgi?id=31688
--- Comment #1 from Fangrui Song ---
We can shorten SECTION_CLASS to CLASS as suggested by
https://inbox.sourceware.org/binutils/CAEdiOyfVYNt8Sq+GGixNek-XMPZaOccx+YSd7QO7eeZy=en...@mail.gmail.com/
--
You are receiving this mail because:
You
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
(https://sourceware.org/pipermail/binutils/2024-May/134009.html RFC:
Maintaining a per-macro invocation count)
gas recently introduced \+ for per-macro invocation counts
https://sourceware.org/bugzilla/show_bug.cgi?id=31752
Fangrui Song changed:
What|Removed |Added
CC||jbeulich at suse dot com
--
You are r
https://sourceware.org/bugzilla/show_bug.cgi?id=31752
--- Comment #1 from Fangrui Song ---
In the absence of the feature, there are a few ways, but none achieves great
efficiency or convenience.
For example, we can define a macro that expands to a sequence of strings: 0,
(0+1), ((0+1)+1), (((0+1
||i at maskray dot me
Resolution|FIXED |---
--- Comment #37 from Fangrui Song ---
I agree with mintsuki . The "-pie -Ttext-segment=non-zero => ET_EXEC" hack
should not be needed.
>From https://sourceware.org/pipermail/binutils/2013
https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #65 from Fangrui Song ---
> > Changing ET_DYN to ET_EXEC fulfills the address requirement but disables
> > ASLR.
> > Is it intentional?
>
> That's my understanding of reading the -Ttext-segment documentation. The
> question is w
https://sourceware.org/bugzilla/show_bug.cgi?id=20520
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #3
https://sourceware.org/bugzilla/show_bug.cgi?id=28812
--- Comment #2 from Fangrui Song ---
This is a feature request. Compressing debug sections is slow. Parallelism,
even with zstd, is pretty important.
--
You are receiving this mail because:
You are on the CC list for the bug.
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
In ELF executables and DSOs, .symtab and .strtab sections can consume a
significant portion of the file size (10+% or even 20+%). In many scenarios, we
cannot remove them due to
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: me at harmenstoppels dot nl
Target Milestone: ---
I've created two static libraries `f/libf.a` and `g/libg.a`. The first
registers a dependency on the second: `-L/path/to/
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: me at harmenstoppels dot nl
Target Milestone: ---
The `libdep.so` plugin allows putting dependency metadata as further command
line arguments `-L/foo -lbar` for the linker in the
https://sourceware.org/bugzilla/show_bug.cgi?id=31904
Harmen Stoppels changed:
What|Removed |Added
Summary|libdep.so plugin does not |libdep.so plugin registers
https://sourceware.org/bugzilla/show_bug.cgi?id=31906
--- Comment #3 from Harmen Stoppels ---
Hi Nick, you're right. But there are larger issues, such as the fact that `\`
isn't escaping anything, it's a "skipped character".
I submitted a patch that addresses the issues reported here as well as
https://sourceware.org/bugzilla/show_bug.cgi?id=31904
--- Comment #2 from Harmen Stoppels ---
Hi Nick,
> The problem is that there is a libg.a in the standard library search paths
> and this is being picked up instead of your local libg.a.
I realized that, changed the title of the bug report,
https://sourceware.org/bugzilla/show_bug.cgi?id=31906
--- Comment #6 from Harmen Stoppels ---
Thanks Nick, looks good to me.
Harmen
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31904
--- Comment #4 from Harmen Stoppels ---
> fixing the bfd linker's not-having-local-search-paths issue, which I think
> might be hard to do
Technically it's not very hard: at least in ld.bfd search paths are a linked
list, so it forms a stack
https://sourceware.org/bugzilla/show_bug.cgi?id=31688
--- Comment #2 from Fangrui Song ---
lld/ELF plans to add CLASS: https://github.com/llvm/llvm-project/pull/95323
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31904
--- Comment #8 from Harmen Stoppels ---
Hi Nick,
I appreciate the patch. Would an additional
`ld_plugin_remove_extra_library_path(const char *path)` be possible so that
> This does however present a problem if multiple archives with
> @samp
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
Tj changed:
What|Removed |Added
CC||tj.iam.tj at proton dot me
--- Comment #8 from
https://sourceware.org/bugzilla/show_bug.cgi?id=31904
--- Comment #10 from Harmen Stoppels ---
Ah OK, I thought add_input_library() was immediate.
Thanks for the patch!
Sounds like this is easier to implement correctly and more convenient to use as
a builtin feature. I could bring that up in a
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #10 from Tj ---
On Friday, 28 June 2024 at 13:52, nsz at gcc dot gnu.org
wrote:
>
> so either linux is wrong for passing
>
> --no-apply-dynamic-relocs -z pack-relative-relocs
>
> together or ld should ignore --no-apply-dynamic
: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
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
https://sourceware.org/bugzilla/show_bug.cgi?id=31955
--- Comment #1 from Fangrui Song ---
Perhaps call this .loc_label , since .cfi_label (2015) is
available.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31924
--- Comment #14 from Tj ---
I see a patch was published in the mailing list on July 2nd but so far it has
not been committed - is there something holding it up?
https://sourceware.org/pipermail/binutils/2024-July/135334.html
--
You are rece
https://sourceware.org/bugzilla/show_bug.cgi?id=31955
Fangrui Song changed:
What|Removed |Added
CC||jbeulich at suse dot com
--
You are r
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #23
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #24 from Fangrui Song ---
(In reply to H.J. Lu from comment #6)
> It also breaks GCC builds for ARM, AVR, PRU and others.
Do you have links to the potentially brittle assembly?
In the gcc repo, I checked a few `rg '\.macro' -g '*
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Data sections without alignment directives (excluding
BSS) might lack '$d' symbols, and mixing data and tex
https://sourceware.org/bugzilla/show_bug.cgi?id=32082
Fangrui Song changed:
What|Removed |Added
Target||arm*-*-* aarch64-*-*
--
You are recei
https://sourceware.org/bugzilla/show_bug.cgi?id=32073
--- Comment #26 from Fangrui Song ---
(In reply to Andreas Schwab from comment #25)
> https://inbox.sourceware.org/binutils/87a5hjmq7r@linux-m68k.org/
Thanks.
https://inbox.sourceware.org/binutils/73460160-a0bf-48d9-84b0-c531317d0...@suse
Version: 2.43.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: a.horodniceanu at proton dot me
Target Milestone: ---
Since commit a6f8fe0a9e9cbe871652e46ba7c22d5e9fb86208
https://sourceware.org/bugzilla/show_bug.cgi?id=32153
Andrei Horodniceanu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--
Priority: P2
Component: gold
Assignee: ccoutant at gmail dot com
Reporter: mail at nh2 dot me
CC: ian at airs dot com
Target Milestone: ---
Hey,
we're trying to link (dynamically) some executables against musl with gold.
When we link wit
https://sourceware.org/bugzilla/show_bug.cgi?id=23856
--- Comment #1 from mail at nh2 dot me ---
This was found as part of https://github.com/NixOS/nixpkgs/issues/49071
--
You are receiving this mail because:
You are on the CC list for the bug
https://sourceware.org/bugzilla/show_bug.cgi?id=23856
mail at nh2 dot me changed:
What|Removed |Added
CC||mail at nh2 dot me
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=23880
howaboutsynergy at pm dot me changed:
What|Removed |Added
CC||howaboutsynergy at pm
https://sourceware.org/bugzilla/show_bug.cgi?id=16428
howaboutsynergy changed:
What|Removed |Added
CC||howaboutsynergy at pm dot me
https://sourceware.org/bugzilla/show_bug.cgi?id=14663
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #8
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
bfd/elf.c
static bfd_boolean
assign_section_numbers (bfd *abfd, struct bfd_link_info
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
clang -fstack-size-section emits a non-alloc SHF_LINK_ORDER section
.stack_sizes linking to .text
[ 2] .text PROGBITS
https://sourceware.org/bugzilla/show_bug.cgi?id=24526
Fangrui Song changed:
What|Removed |Added
Component|gold|ld
--- Comment #1 from Fangrui Song -
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
This depends on https://sourceware.org/bugzilla/show_bug.cgi?id=24526
(Generalize GC support for SHF_LINK_ORDER)
# a.script
SECTIONS { /DISCARD/ : { *(.foo
https://sourceware.org/bugzilla/show_bug.cgi?id=25020
--- Comment #2 from Fangrui Song ---
I mean the error should probably be issued for any discarded section.
.globl _start
_start:
call .foo1
call baz0
call baz1
.section .foo0,"a"
.byte 0
.section .foo1,"a"
.byte 0
## The linked-to se
https://sourceware.org/bugzilla/show_bug.cgi?id=24942
--- Comment #9 from Fangrui Song ---
I don't require the support for non power-of-2 alignment. I just want to say
--set-section-alignment .foo=8 => sh_addralign=256 is counterintuitive. It is
not what readelf -S displays. (objdump -h displays
https://sourceware.org/bugzilla/show_bug.cgi?id=24942
--- Comment #12 from Fangrui Song ---
> Created attachment 12002 [details]
if (palign <= 0 || palign & (palign-1))
can be used to simplify the code.
--
You are receiving this mail because:
You are on the CC list for the bug.
__
https://sourceware.org/bugzilla/show_bug.cgi?id=24942
--- Comment #13 from Fangrui Song ---
Ping:)
FWIW, I have a patch to implement --set-section-alignment in llvm-objcopy
https://reviews.llvm.org/D67656 . I don't want to cause gratuitous differences
from GNU objcopy, so I haven't committed tha
iority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
cat > a.x < a.s < b.s <
https://sourceware.org/bugzilla/show_bug.cgi?id=23825
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #6
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
int main() {}
% gcc -fuse-ld=bfd a.c -Wl,-Ttext-segment,0x30 -z noseparate-code -o a;
readelf
erity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Originally reported at https://bugs.llvm.org//show_bug.cgi?id=43748 but it
turns out to be related to openmpi and GNU ld.
https://sourceware.org/bugzilla/show_bug.cgi?id=25236
--- Comment #1 from Fangrui Song ---
symbol versioning is always enabled. openmpi may need a workaround
https://github.com/open-mpi/ompi/issues/7209
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=25236
--- Comment #3 from Fangrui Song ---
Maybe we should discuss on the generic ABI mailing list. It is very late here
(01:00) so I'll not do that now. If you create a thread, can you CC me?
My feeling is that a STN_COMMON (STT_C
https://sourceware.org/bugzilla/show_bug.cgi?id=25236
--- Comment #6 from Fangrui Song ---
To make sure we are on the same page. In the case that both a.o and a.so define
the common symbol:
The definition from a.o wins. --version-script should apply versions on the
definition. At runtime, the sh
: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.s
vmload %rax
vmrun %rax
vmsave %rax
% as a.s -o a.o
% objdump -d a.o
a.o: file format elf64-x86-64
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
These directives are allowed without an operand.
.balign
.align
.p2align
Such forms should probably be removed.
--
You are receiving this mail because:
You
https://sourceware.org/bugzilla/show_bug.cgi?id=14891
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #2
NCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Clang's integrated assembler supports multiple section with the same name.
% cat a.s
.section
iority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.c
void foo(){}
void bar(){}
% clang -fpatchable-function-entry=2 -ffunction-sections -S a.c #
https://sourceware.org/bugzilla/show_bug.cgi?id=25371
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #3
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat pcrel-global.s
.syntax unified
.globl foo
foo:
ldrd r0, r1, foo @ arm_pcrel_10_unscaled
vldr d0, foo
https://sourceware.org/bugzilla/show_bug.cgi?id=25371
--- Comment #4 from Fangrui Song ---
https://sourceware.org/ml/binutils/2020-01/msg00186.html
in the spirit of a previous patch by HJ. Lu that makes SHF_EXCLUDE generic
rather than processor-specific.
--
You are receiving this mail because:
101 - 200 of 527 matches
Mail list logo
