11 Commits

Author SHA1 Message Date
Richard Dzenis
334a5766d7
[llvm-objcopy] Add support of symbol modification flags for MachO (#120895)
This patch adds support of the following llvm-objcopy flags for MachO:

- `--globalize-symbol`, `--globalize-symbols`,
- `--keep-global-symbol`, `-G`, `--keep-global-symbols`,
- `--localize-symbol`, `-L`, `--localize-symbols`,
- `--skip-symbol`, `--skip-symbols`.

Code in `updateAndRemoveSymbols` for MachO
is kept similar to its version for ELF.

Fixes #120894
2024-12-24 16:05:10 +02:00
Dan Zimmerman
0807846a9e
[objcopy] Implement --weaken, --weaken-symbol(s) flags for Mach-O Object Files (#70560)
This PR implements --weaken, --weaken-symbol(s)  flags in llvm-objcopy for Mach-O.

Test plan: ninja check-all
2023-11-06 01:20:52 -08:00
zhijian
f740bcb370 [AIX] supporting -X options for llvm-ranlib in AIX OS
Summary:

llvm-ar is symlinked as llvm-ranlib and will act as ranlib when invoked in that mode. llvm-ar since [[ 4f2cfbe531 | compiler/llvm-project@4f2cfbe ]] supports the -X options, but doesn't seem to accept them when running as llvm-ranlib.

In AIX OS , according to https://www.ibm.com/docs/en/aix/7.2?topic=r-ranlib-command

-X mode 	Specifies the type of object file ranlib should examine. The mode must be one of the following:

32
    Processes only 32-bit object files
64
    Processes only 64-bit object files
32_64, any
    Processes both 32-bit and 64-bit object files

The default is to process 32-bit object files (ignore 64-bit objects). The mode can also be set with the OBJECT_MODE environment variable. For example, OBJECT_MODE=64 causes ranlib to process any 64-bit objects and ignore 32-bit objects. The -X flag overrides the OBJECT_MODE variable.

Reviewers: James Henderson, MaskRay, Stephen Peckham
Differential Revision: https://reviews.llvm.org/D142660
2023-08-22 09:41:33 -04:00
Mike Hommey
57dc16fbe3
[llvm] Strip stabs symbols in Mach-O when stripping debug info 2023-06-03 09:31:42 +02:00
Gregory Alfonso
d22f050e15 Remove redundant .c_str() and .get() calls
Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D139485
2022-12-18 00:33:53 +00:00
Fangrui Song
ec941432cf [ObjCopy] llvm::Optional => std::optional 2022-12-10 19:46:02 +00:00
Kazu Hirata
7a47ee51a1 [llvm] Don't use Optional::getValue (NFC) 2022-06-20 22:45:45 -07:00
Keith Smiley
066243057f
[Object] Fix updating darwin archives
When creating an archive, llvm-ar looks at the host to determine the
archive format to use, on Apple platforms this means it uses the
K_DARWIN format. K_DARWIN is _virtually_ equivalent to K_BSD, expect for
some very slight differences around padding, timestamps in deterministic
mode, and 64 bit formats. When updating an archive using llvm-ar, or
llvm-objcopy, Archive would try to determine the kind, but it was not
possible to get K_DARWIN in the initialization of the archive, because
they're virtually inciting usable from K_BSD, especially since the
slight differences only apply in very specific cases. This leads to
linker failures when the alignment workaround is not applied to an
archive copied with llvm-objcopy. This change teaches Archive to infer
the K_DARWIN type in the cases where it's possible and the first object
in the archive is a macho object. This avoids using the host triple to
determine this to not affect cross compiling.

Ideally we would eliminate the separate K_DARWIN type entirely since
it's not a truly separate archive type, but then we'd have to force the
macho workarounds on the BSD format generally. This might be acceptable
but then it would be unclear how to handle this case without forcing the
K_DARWIN64 format on all BSD users:

```
if (LastOffset >= Sym64Threshold) {
  if (Kind == object::Archive::K_DARWIN)
    Kind = object::Archive::K_DARWIN64;
  else
    Kind = object::Archive::K_GNU64;
}
```

The logic used to determine if the object is macho is derived from the
logic llvm-ar uses.

Previous context:

- 111cd669e90e5b2132187d36f8b141b11a671a8b
- 23a76be5adcaa768ba538f8a4514a7afccf61988

Differential Revision: https://reviews.llvm.org/D124895
2022-05-19 10:56:26 -07:00
Richard Howell
5917219438 [llvm] remove empty __LLVM segment in llvm-bitcode-strip
When running llvm-bitcode-strip we want to remove the __LLVM
segment as well as the __bundle section when there are no other
sections in the segment.

Differential Revision: https://reviews.llvm.org/D120927
2022-03-07 08:52:25 -08:00
Alexey Lapshin
a6f3fedc3f [objcopy] Refactor CommonConfig to add posibility to specify added/updated sections as MemoryBuffer.
Current objcopy implementation has a possibility to add or update sections.
The incoming section is specified as a pair: section name and name of the file
containing section data. The interface does not allow to specify incoming
section as a memory buffer. This patch adds possibility to specify incoming
section as a memory buffer.

Differential Revision: https://reviews.llvm.org/D120486
2022-03-01 14:49:41 +03:00
Alexey Lapshin
f75da0c8e6 [llvm-objcopy][NFC] Move core implementation of llvm-objcopy into separate library.
This patch moves core implementation of llvm-objcopy into Object library
(http://lists.llvm.org/pipermail/llvm-dev/2020-September/145075.html).
The functionality for parsing input options is left inside tools/llvm-objcopy.
The interface of ObjCopy library:

ObjCopy/ELF/ELFObjcopy.h

```
Error executeObjcopyOnIHex(const CopyConfig &Config, MemoryBuffer &In,
                           Buffer &Out);
Error executeObjcopyOnRawBinary(const CopyConfig &Config, MemoryBuffer &In,
                                Buffer &Out);
Error executeObjcopyOnBinary(const CopyConfig &Config,
                             object::ELFObjectFileBase &In, Buffer &Out);

```
ObjCopy/COFF/COFFObjcopy.h

```
Error executeObjcopyOnBinary(const CopyConfig &Config,
                             object::COFFObjectFile &In, Buffer &Out);

```
ObjCopy/MachO/MachOObjcopy.h

```
Error executeObjcopyOnBinary(const CopyConfig &Config,
                             object::MachOObjectFile &In, Buffer &Out);

```
ObjCopy/wasm/WasmObjcopy.h

```
Error executeObjcopyOnBinary(const CopyConfig &Config,
                             object::WasmObjectFile &In, Buffer &Out);

```

Differential Revision: https://reviews.llvm.org/D88827
2022-02-17 13:11:42 +03:00