https://sourceware.org/bugzilla/show_bug.cgi?id=32459
--- Comment #4 from Fangrui Song ---
Sorry again for the late reply.
Since objdump -r ignores dynamic relocations, I think it is consistent to not
report a warning when .relr.dyn is present.
% objdump -r /bin/ls
/bin/ls: file format elf
: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Apple ld64 implements -why_live sym
> Logs a chain of references to symbol_name. Only applicable with -dead_strip .
> It can help debug why something that you think should be dead strip removed
https://sourceware.org/bugzilla/show_bug.cgi?id=32591
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4
https://sourceware.org/bugzilla/show_bug.cgi?id=32459
--- Comment #2 from Fangrui Song ---
Hi Nick,
Sorry for my late reply and happy new year!
I favor 1) for its simplicity. I do think it's tricky to share code between
readelf (no BFD dependency) and objdump. It's probably good enough to encou
: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
readelf -r dumps RELR relocations while objdump -R doesn't. Should objdump -R
dump RELR as well?
% readelf -W -r a
Relocation section '.rela.dyn' at offset 0
https://sourceware.org/bugzilla/show_bug.cgi?id=27566
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #11
https://sourceware.org/bugzilla/show_bug.cgi?id=32153
Andrei Horodniceanu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--
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=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
https://sourceware.org/bugzilla/show_bug.cgi?id=32082
Fangrui Song changed:
What|Removed |Added
Target||arm*-*-* aarch64-*-*
--
You are recei
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=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 '*
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=31955
Fangrui Song changed:
What|Removed |Added
CC||jbeulich at suse dot com
--
You are r
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
--- 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.
: 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=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
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
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 #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=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 #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=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 #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 #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
Harmen Stoppels changed:
What|Removed |Added
Summary|libdep.so plugin does not |libdep.so plugin registers
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
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/
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
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.
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=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
||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=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
https://sourceware.org/bugzilla/show_bug.cgi?id=31752
Fangrui Song changed:
What|Removed |Added
CC||jbeulich at suse dot com
--
You are r
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=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
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
: 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=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
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=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
https://sourceware.org/bugzilla/show_bug.cgi?id=31475
Fangrui Song changed:
What|Removed |Added
Summary|binutils: Support RELLEB|binutils: Support CREL
: 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=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
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=31409
Fangrui Song changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--
You are r
: 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
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
https://sourceware.org/bugzilla/show_bug.cgi?id=31408
Fangrui Song changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
T
https://sourceware.org/bugzilla/show_bug.cgi?id=31407
Fangrui Song changed:
What|Removed |Added
Target||arm*-*-uclinuxfdpiceabi
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=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
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 #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=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=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 #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
: 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 #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
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=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
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
||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
https://sourceware.org/bugzilla/show_bug.cgi?id=31077
Yannik Sembritzki changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNC
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
Summary|objcopy |objcopy has
|--
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
: 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=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
>
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=30907
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #4
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
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
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
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
Fangrui Song changed:
What|Removed |Added
CC||jrtc27 at jrtc27 dot com,
: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
From
https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#ld---emit-relocs
(with updated instructions)
For
https://sourceware.org/bugzilla/show_bug.cgi?id=30612
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #1
https://sourceware.org/bugzilla/show_bug.cgi?id=30788
Fangrui Song changed:
What|Removed |Added
Target||aarch64*-*
--
You are receiving this
Status: NEW
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Extracted from https://github.com/llvm/llvm-project/issues/63418
```
cat > a.s <
viour needed to be gated
> by a command line option, so I have added --extra-sym-info to do this.
Thank you for implementing this! Yes, I think quite a few projects rely on the
output of readelf -Ws. Using an opt-in option is necessary. The option name
-X/--extra-sym-info looks good to me. Ano
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
I almost always prefer readelf -Ws to objdump -t for ELF symbol information as
the former presents all information without distortion. Certain symbol types
have
|unassigned at sourceware dot org |i at maskray dot me
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #2 from Fangrui Song ---
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5e24da908dbf6ddeb03e2b194f6b39dea3c660f3
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
It will be more convenient if --set-section-flags supports toggling a flag,
instead of specifying the full set of flags, e.g.
--set-section-flags .foo=-alloc
https://sourceware.org/bugzilla/show_bug.cgi?id=30374
--- Comment #5 from Fangrui Song ---
(In reply to Nick Clifton from comment #4)
> OK, I have decided to commit my patch now, so that it gets into the next
> release. If there are problems we can always reopen this PR.
Thank you! I have tested
https://sourceware.org/bugzilla/show_bug.cgi?id=30592
--- Comment #1 from Fangrui Song ---
Patch: https://sourceware.org/pipermail/binutils/2023-June/128052.html
--
You are receiving this mail because:
You are on the CC list for the bug.
ty: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Linkers may place SHF_X86_64_LARGE sections away from regular sections to
alleviate relocation overflow pressure [1]. I
https://sourceware.org/bugzilla/show_bug.cgi?id=27452
--- Comment #1 from Fangrui Song ---
I think we should just allow SHF_ALLOC | SHF_COMPRESSED sections. Created
https://groups.google.com/g/generic-abi/c/HUVhliUrTG0
The proposed option syntax is: --compress-sections='.debug_*=zlib' . This
app
https://sourceware.org/bugzilla/show_bug.cgi?id=16523
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #1
https://sourceware.org/bugzilla/show_bug.cgi?id=30237
--- Comment #7 from Fangrui Song ---
(In reply to Andreas Schwab from comment #6)
> Since arm32 does not have PT_ARM_ATTRIBUTES it cannot have this problem in
> the first place.
With the PHDRS linker script command, we can customize program h
https://sourceware.org/bugzilla/show_bug.cgi?id=30237
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #5
https://sourceware.org/bugzilla/show_bug.cgi?id=30449
Fangrui Song changed:
What|Removed |Added
Target||riscv*-*-*
--
You are receiving this
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
"lga" has been in riscv-asm-manual since the resolution to
https://github.com/riscv-non-isa/riscv-asm-manual/issues/50
In LLVM 17, LLVM integrated assembl
https://sourceware.org/bugzilla/show_bug.cgi?id=30426
Fangrui Song changed:
What|Removed |Added
Target||i686* x86_64*
--
You are receiving th
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
% cat a.s
call [offset func]
jmp [offset func]
% as -msyntax=intel a.s -o a.o
% objdump -M intel -dr a.o
a.o: file format elf64-x86
https://sourceware.org/bugzilla/show_bug.cgi?id=30374
--- Comment #1 from Fangrui Song ---
I have picked `=` as a separator a la -fdebug-prefix-map=. --remap-inputs= may
be handy to specify just one pattern. Here is an example:
--remap-inputs-file=1.map --remap-inputs-file=2.map --remap-inputs='
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: i at maskray dot me
Target Milestone: ---
Hello! I'm considering an option in ld.lld to replace or remove input files
with glob patterns. https://reviews.llvm.org/D148859
--remap-inputs-file= can be spec
https://sourceware.org/bugzilla/show_bug.cgi?id=27565
--- Comment #3 from Fangrui Song ---
(In reply to Nick Clifton from comment #2)
> Created attachment 14772 [details]
> Proposed patch
>
> Hi Fanguri,
>
> What do you think of this patch ? Does it do what you need ?
>
> Cheers
> Nick
H
1 - 100 of 523 matches
Mail list logo
