OBJCOPY(1)

๐Ÿ’… OBJCOPY(1) โ€” GNU Development Tools ๐Ÿ’…

okay bestie, sit down, hydrate, because we're about to talk about objcopy, and she is honestly iconic. this is the manual page for it, from the GNU Development Tools corner of the universe. part 1 of 5, so buckle up ๐ŸŽ€


โœจ NAME โœจ

objcopy โ€” copy and translate object files. that's it. that's the job. she copies, she translates, she slays ๐Ÿ’–


๐ŸŒธ SYNOPSIS ๐ŸŒธ

here's the whole shape of her, every flag, nothing skipped, because we do not gatekeep here:

objcopy [-F bfdname|--target=bfdname]
        [-I bfdname|--input-target=bfdname]
        [-O bfdname|--output-target=bfdname]
        [-B bfdarch|--binary-architecture=bfdarch]
        [-S|--strip-all]
        [-g|--strip-debug]
        [--strip-unneeded]
        [-K symbolname|--keep-symbol=symbolname]
        [--keep-file-symbols]
        [--keep-section-symbols]
        [-N symbolname|--strip-symbol=symbolname]
        [--strip-unneeded-symbol=symbolname]
        [-G symbolname|--keep-global-symbol=symbolname]
        [--localize-hidden]
        [-L symbolname|--localize-symbol=symbolname]
        [--globalize-symbol=symbolname]
        [--globalize-symbols=filename]
        [-W symbolname|--weaken-symbol=symbolname]
        [-w|--wildcard]
        [-x|--discard-all]
        [-X|--discard-locals]
        [-b byte|--byte=byte]
        [-i [breadth]|--interleave[=breadth]]
        [--interleave-width=width]
        [-j sectionpattern|--only-section=sectionpattern]
        [-R sectionpattern|--remove-section=sectionpattern]
        [--keep-section=sectionpattern]
        [--remove-relocations=sectionpattern]
        [--strip-section-headers]
        [-p|--preserve-dates]
        [-D|--enable-deterministic-archives]
        [-U|--disable-deterministic-archives]
        [--debugging]
        [--gap-fill=val]
        [--pad-to=address]
        [--set-start=val]
        [--adjust-start=incr]
        [--change-addresses=incr]
        [--change-section-address sectionpattern{=,+,-}val]
        [--change-section-lma sectionpattern{=,+,-}val]
        [--change-section-vma sectionpattern{=,+,-}val]
        [--change-warnings] [--no-change-warnings]
        [--set-section-flags sectionpattern=flags]
        [--set-section-alignment sectionpattern=align]
        [--add-section sectionname=filename]
        [--dump-section sectionname=filename]
        [--update-section sectionname=filename]
        [--rename-section oldname=newname[,flags]]
        [--long-section-names {enable,disable,keep}]
        [--change-leading-char] [--remove-leading-char]
        [--reverse-bytes=num]
        [--srec-len=ival] [--srec-forceS3]
        [--redefine-sym old=new]
        [--redefine-syms=filename]
        [--weaken]
        [--keep-symbols=filename]
        [--strip-symbols=filename]
        [--strip-unneeded-symbols=filename]
        [--keep-global-symbols=filename]
        [--localize-symbols=filename]
        [--weaken-symbols=filename]
        [--binary-symbol-prefixstring]
        [--add-symbol name=[section:]value[,flags]]
        [--alt-machine-code=index]
        [--prefix-symbols=string]
        [--prefix-sections=string]
        [--prefix-alloc-sections=string]
        [--add-gnu-debuglink=path-to-file]
        [--only-keep-debug]
        [--strip-dwo]
        [--extract-dwo]
        [--extract-symbol]
        [--writable-text]
        [--readonly-text]
        [--pure]
        [--impure]
        [--file-alignment=num]
        [--heap=reserve[,commit]]
        [--image-base=address]
        [--section-alignment=num]
        [--stack=reserve[,commit]]
        [--subsystem=which:major.minor]
        [--compress-debug-sections]
        [--decompress-debug-sections]
        [--elf-stt-common=val]
        [--merge-notes]
        [--no-merge-notes]
        [--verilog-data-width=val]
        [-v|--verbose]
        [-V|--version]
        [--help] [--info]
        infile [outfile]

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

so. the GNU objcopy utility? she copies the contents of one object file into another. that's the whole vibe. she uses the GNU BFD Library to read and write those object files, and โ€” this is the part that eats โ€” she can write the destination object file in a format that's different from the source's format. the exact behavior is all controlled by command-line options, so basically you're the main character and she does what you say ๐Ÿ’…

lowkey important: objcopy should be able to copy a fully linked file between any two formats. but copying a relocatable object file between any two formats may not work as expected. not a vibe, just a fact. no cap.

objcopy creates temporary files to do its translations and deletes them afterward. she uses BFD for literally all of her translation work, which means she has access to every format described in BFD, and thus can recognize most formats without you having to tell her explicitly. she just knows. iykyk โœจ

you can use objcopy to generate S-records by using an output target of srec (e.g., use -O srec).

you can also use objcopy to generate a raw binary file by using an output target of binary (e.g., use -O binary). when she generates a raw binary file, she essentially produces a memory dump of the contents of the input object file. all symbols and relocation information will be discarded. the memory dump will start at the load address of the lowest section copied into the output file.

when you're generating an S-record or a raw binary file, it may be helpful to use -S to remove sections containing debugging information. in some cases -R will be useful to remove sections which contain information that is not needed by the binary file. tiny cleanup, big difference ๐Ÿงš

Note โ€” objcopy is not able to change the endianness of its input files. if the input format has an endianness (some formats do not), objcopy can only copy the inputs into file formats that have the same endianness or which have no endianness (e.g., srec). (however, see the --reverse-bytes option.) she's not a magician, bestie, she's a copier ๐Ÿ˜ญ

๐Ÿ‘‘ OPTIONS ๐Ÿ‘‘

the whole menu. every single one. she did not come to play.

  • infile โ€” the input file, respectively. (yes, "respectively" โ€” the pairing is with outfile, keep reading ๐Ÿซถ)
  • outfile โ€” the output file. if you do not specify outfile, objcopy creates a temporary file and destructively renames the result with the name of infile. destructive!! in a cute way?? sort of. watch out for that one.
  • -I bfdname, --input-target=bfdname โ€” treat the source file's object format as bfdname instead of trying to deduce it yourself. she's guessing otherwise, so this is you telling her, confidently: it's this one ๐Ÿ’
  • -O bfdname, --output-target=bfdname โ€” write the output file using the object format bfdname. glow-up, but for formats.
  • -F bfdname, --target=bfdname โ€” use bfdname as the object format for both the input and the output file. i.e., you're simply transferring data from source to destination with no translation. straight through, no detours ๐ŸŒˆ
  • -B bfdarch, --binary-architecture=bfdarch โ€” useful when you're transforming an architecture-less input file into an object file. in that case you can set the output architecture to bfdarch. this option gets ignored if the input file already has a known bfdarch. you can access this binary data inside a program by referencing the special symbols that the conversion process creates. those symbols are called _binary_objfile_start, _binary_objfile_end and _binary_objfile_size. e.g. you can transform a picture file into an object file and then access it in your code using these symbols. literally turning a png into a personality ๐ŸŽ€
  • -j sectionpattern, --only-section=sectionpattern โ€” copy only the sections you point at, from input to output. this option may be given more than once. note that using this option inappropriately may make the output file unusable. wildcard characters are accepted in sectionpattern.

if the first character of sectionpattern is the exclamation point (!) then matching sections will not be copied, even if an earlier use of --only-section on the same command line would otherwise copy it. for example:

--only-section=.text.* --only-section=!.text.foo

will copy all sections matching .text.* but not the section .text.foo. exclusion list energy โœจ

  • -R sectionpattern, --remove-section=sectionpattern โ€” remove any section matching sectionpattern from the output file. may be given more than once. note that using this option inappropriately may make the output file unusable. wildcard characters are accepted in sectionpattern. using both the -j and -R options together results in undefined behaviour โ€” do not do that, bestie, that's chaos.

if the first character of sectionpattern is the exclamation point (!) then matching sections will not be removed, even if an earlier use of --remove-section on the same command line would otherwise remove it. for example:

--remove-section=.text.* --remove-section=!.text.foo

will remove all sections matching the pattern .text.*, but will not remove the section .text.foo.

  • --keep-section=sectionpattern โ€” when removing sections from the output file, keep the sections that match sectionpattern. protection spell ๐Ÿ›ก๏ธ
  • --remove-relocations=sectionpattern โ€” remove non-dynamic relocations from the output file for any section matching sectionpattern. this option may be given more than once. note that using this option inappropriately may make the output file unusable, and attempting to remove a dynamic relocation section such as .rela.plt from an executable or shared library with --remove-relocations=.plt will not work. wildcard characters are accepted in sectionpattern. for example:
--remove-relocations=.text.*

will remove the relocations for all sections matching the pattern .text.*.

if the first character of sectionpattern is the exclamation point (!) then matching sections will not have their relocation removed, even if an earlier use of --remove-relocations on the same command line would otherwise cause the relocations to be removed. for example:

--remove-relocations=.text.* --remove-relocations=!.text.foo

will remove all relocations for sections matching the pattern .text.*, but will not remove relocations for the section .text.foo.

  • --strip-section-headers โ€” strip section header. this option is specific to ELF files. implies --strip-all and --merge-notes. she takes the headers and the notes situation with her ๐Ÿ’€
  • -S, --strip-all โ€” do not copy relocation and symbol information from the source file. also deletes debug sections. full clear-out ๐Ÿงน
  • -g, --strip-debug โ€” do not copy debugging symbols or sections from the source file. just the debug stuff. the rest stays cute.
  • --strip-unneeded โ€” remove all symbols that are not needed for relocation processing, in addition to the debugging symbols and sections stripped by --strip-debug. she's thorough and she's not sorry.
  • -K symbolname, --keep-symbol=symbolname โ€” when stripping symbols, keep symbol symbolname even if it would normally be stripped. this option may be given more than once. keeping her safe ๐Ÿฅบ
  • -N symbolname, --strip-symbol=symbolname โ€” do not copy symbol symbolname from the source file. this option may be given more than once.
  • --strip-unneeded-symbol=symbolname โ€” do not copy symbol symbolname from the source file unless it is needed by a relocation. this option may be given more than once.
  • -G symbolname, --keep-global-symbol=*symbolname* โ€” okay so this one is a whole pick me move for exactly one symbol ๐Ÿ’… it keeps only symbolname global and makes every single other symbol local to the file, so they're not visible externally anymore. You can stack this one as many times as you want. But bestie, heads up: you cannot use this with --globalize-symbol or --globalize-symbols. They're beefing, pick a side ๐Ÿ˜ค
  • --localize-hidden โ€” for ELF objects: every symbol with hidden or internal visibility gets marked local. And it stacks on top of the symbol-specific localization stuff like -L. Layering, we love to see it โœจ
  • -L symbolname, --localize-symbol=*symbolname* โ€” turns a global or weak symbol named symbolname into a local one so it's not visible externally. Stackable, go off ๐Ÿซถ ngl though โ€” unique symbols are not converted. That's the rule, that's the vibe.
  • -W symbolname, --weaken-symbol=*symbolname* โ€” makes symbolname weak. That's it, that's the whole job. Use it more than once if you want ๐Ÿ’œ
  • --binary-symbol-prefix=*string* โ€” when you're rocking --input-target=binary, this sets string as the base name for the symbols generated from the input file. Those symbols are:
<string>_start
<string>_end
<string>_size

By default the binary input handler cooks up the prefix from a mangled version of the input file name plus the _binary prefix. This flag just lets you say it out loud yourself, explicitly, no guessing ๐ŸŽ€

  • --globalize-symbol=*symbolname* โ€” gives symbolname global scoping so it's visible outside the file it's defined in. Stackable. But fr fr โ€” cannot be combined with -G or --keep-global-symbol. Same beef as before, no crossover episodes ๐Ÿ™…โ€โ™€๏ธ
  • -w, --wildcard โ€” this one unlocks regular expressions in the symbolnames you use in other command line options ๐Ÿ”ฅ The operators ?, *, \ and [] can go anywhere in the symbol name. And plot twist: if the first character of the symbol name is !, then the sense of the switch gets reversed for that symbol. Example time:
-w -W !foo -W fo*

which would make objcopy weaken every symbol starting with "fo" except for "foo". The exclamation mark said not today ๐Ÿ˜Œ

  • -x, --discard-all โ€” do not copy non-global symbols from the source file. Bye bye, not-globals ๐Ÿ‘‹
  • -X, --discard-locals โ€” do not copy compiler-generated local symbols. (Those usually start with L or ..) Compiler's little homemade guys, leaving them at home ๐Ÿ 
  • -b byte, --byte=*byte* โ€” if interleaving is on (via --interleave), this is where you say start the range of bytes to keep at the byte-th byte. byte can be anywhere from 0 to breadth-1, where breadth is whatever value you fed to --interleave. Basic math, slay ๐Ÿงฎ
  • -i [breadth], --interleave[=*breadth*] โ€” only copies a range out of every breadth bytes. (Header data is not affected, so don't worry about it.) Which byte in the range kicks off the copy? That's --byte. How wide is the range? That's --interleave-width.

This is the ROM-programming girly option, it's giving embedded dev realness. Typically paired with an "srec" output target. And ngl โ€” objcopy will complain if you don't specify --byte too. It needs its bestie ๐Ÿ˜ญ

The default interleave breadth is 4, so with --byte set to 0, objcopy would copy the first byte out of every four bytes from input to output. Cute, efficient, iconic.

  • --interleave-width=*width* โ€” when used with --interleave, copy width bytes at a time. Where the range starts is set by --byte, and how far the range goes is set by --interleave.

Default value is 1. And the rule is: width plus the byte value from --byte must not exceed the interleave breadth from --interleave. Do not test it, it will not pass ๐Ÿ’€

Now the fun part โ€” you can use this to build images for two 16-bit flashes interleaved in a 32-bit bus by passing -b 0 -i 4 --interleave-width=2 to one objcopy and -b 2 -i 4 --interleave-width=2 to another. If the input was '12345678' then the outputs would be '1256' and '3478'. Not me doing math that actually works ๐Ÿ˜ณโœจ

  • -p, --preserve-dates โ€” sets the access and modification dates of the output file to be the exact same as the input file's. Matching, as they should ๐Ÿ’…

It also copies the date stored in a PE format file's header โ€” unless the SOURCE_DATE_EPOCH environment variable is defined. If it is defined, then that variable gets used as the date stored in the header, interpreted as the number of seconds since the Unix epoch. Environment variables really said I'll take it from here ๐Ÿ•ฐ๏ธ

  • -D, --enable-deterministic-archives โ€” deterministic mode, activated ๐ŸŽฏ when copying archive members and writing the archive index, it uses zero for UIDs, GIDs and timestamps, plus consistent file modes for all files. Everything same, everything predictable, reproducible builds queen.

If binutils was configured with --enable-deterministic-archives, then this mode is on by default โ€” and it can be turned off with the -U option below.

  • -U, --disable-deterministic-archives โ€” do not operate in deterministic mode. It's the inverse of -D up there: when copying archive members and writing the archive index, it uses their actual UID, GID, timestamp and file mode values. Real ones only ๐Ÿซก

This is the default unless binutils was configured with --enable-deterministic-archives.

  • --debugging โ€” converts debugging information, if possible. It is not the default because only certain debugging formats are supported and the conversion process can be time consuming. Optional for a reason, bestie โณ
  • --gap-fill val โ€” fills the gaps between sections with val. This applies to the load address (LMA) of the sections. How it works: it increases the size of the section with the lower address, and fills the extra space it just made with val. Gap? Filled. Periodt ๐Ÿ’–
  • --pad-to address โ€” pads the output file up to the load address address. Same move: increasing the size of the last section. The extra space gets filled with whatever --gap-fill says โ€” and the default is zero.
  • --set-start val โ€” sets the start address (also known as the entry address) of the new file to val. Just a warning though: not all object file formats support setting the start address. Know your format.
  • --change-start incr, --adjust-start incr โ€” changes the start address (yeah, the entry address) by adding incr. Same energy as above: not all object file formats support setting the start address.
  • --change-addresses incr, --adjust-vma incr โ€” changes the VMA and LMA addresses of all sections, plus the start address, by adding incr. Some object file formats don't permit section addresses to be changed arbitrarily, so. Yikes.
And listen: this does not relocate the sections. If the program expects sections to be loaded at a certain address, and you use this to move them somewhere else, the program may fail. That's not a vibe, that's a crash ๐Ÿšจ
  • --change-section-address sectionpattern{=|+|-}val, --adjust-section-vma sectionpattern{=|+|-}val โ€” sets or changes both the VMA address and the LMA address of any section matching sectionpattern. If = is used, the section address is set to val. Otherwise, val is added to or subtracted from the section address. Go read the comments under --change-addresses above. And if sectionpattern doesn't match any sections in the input file, a warning will be issued โ€” unless you're using --no-change-warnings. Fair warning system fr.
  • --change-section-lma sectionpattern{=|+|-}val โ€” sets or changes the LMA address of any sections matching sectionpattern. The LMA address is the address where the section will be loaded into memory at program load time. Normally this is the same as the VMA address โ€” which is the address of the section at program run time โ€” but on some systems, especially ones where a program is held in ROM, the two can be different. If = is used, the section address is set to val. Otherwise, val is added to or subtracted from the section address. See the comments under --change-addresses, above. If sectionpattern doesn't match any sections in the input file, a warning will be issued unless --no-change-warnings is used. Same rules, same drama, but LMA edition ๐Ÿซถ
  • --change-section-vma sectionpattern{=|+|-}val โ€” sets or changes the VMA address of any section matching sectionpattern. The VMA address is where the section will be located once the program has started executing. Normally it equals the LMA address (the address where the section is loaded into memory), but on some systems โ€” especially those where a program is held in ROM โ€” the two can be different. If = is used, the section address is set to val. Otherwise, val is added to or subtracted from the section address. Comments under --change-addresses, above. And if sectionpattern doesn't match any sections in the input file, warning issued, unless --no-change-warnings.
Extra spicy note: changing the VMA of sections in a fully linked binary can be dangerous, since there may be code that expects the sections to sit at their old address. Danger, Will Robinson ๐Ÿ’€
  • --change-warnings, --adjust-warnings โ€” if --change-section-address, --change-section-lma or --change-section-vma is used and the section pattern doesn't match anything, issue a warning. And this is the default. The software is looking out for you ๐ŸŒธ
  • --no-change-warnings, --no-adjust-warnings โ€” do not issue a warning if --change-section-address, --adjust-section-lma or --adjust-section-vma is used, even when the section pattern matches zero sections. Silence, on purpose ๐Ÿš
  • --set-section-flags sectionpattern=flags โ€” sets the flags for any sections matching sectionpattern. The flags argument is a comma separated string of flag names. The recognized names are alloc, contents, load, noload, readonly, code, data, rom, exclude, share, debug, and large.

Now the fine print, bestie: you can set the contents flag for a section that has no contents, but it is not meaningful to clear the contents flag of a section that does have contents โ€” instead, just remove the section. And not all flags are meaningful for all object file formats. In particular, the share flag is only meaningful for COFF format files and not for ELF format files. The ELF x86-64 specific flag large corresponds to SHF_X86_64_LARGE. Know your format, know your flags ๐ŸŽ€

  • --set-section-alignment sectionpattern=align โ€” sets the alignment for any sections matching sectionpattern. align specifies the alignment in bytes and must be a power of two, i.e. 1, 2, 4, 8.... Yes, in that order, don't be creative โœจ
Quick lil heads up bestie โ€” setting a section's alignment does not automatically align its LMA or VMA addresses. If those need changing too, you gotta reach for the --change-section-lma and/or --change-section-vma options. Also ๐Ÿ’€ changing VMAs can cause problems in fully linked binaries, because there may be code out there that expects the section contents to live at their old address. So like, be careful, okay?

  • --add-section sectionname=filename โ€” adds a brand new section called sectionname while it's copying the file ๐ŸŽ€ The contents of the new section come straight from filename, and the section's size will be the size of that file. This only works on file formats that can support sections with arbitrary names, so vibe check your format first. Lowkey important: it may be necessary to use --set-section-flags to set the attributes of the newly created section. ๐Ÿ‘‘
  • --dump-section sectionname=filename โ€” takes the contents of the section named sectionname and drops them into filename, overwriting whatever was there before (sorry to the previous contents, they're gone ๐Ÿ™ˆ). This option is the inverse of --add-section. It's similar to --only-section except it does not create a formatted file โ€” it just dumps the contents as raw binary data, with no relocations applied. You can specify this option more than once.
  • --update-section sectionname=filename โ€” replaces the existing contents of the section named sectionname with the contents of filename. The section size gets adjusted to the size of the file ๐Ÿฆ‹ The section flags for sectionname stay unchanged. And for ELF format files the section-to-segment mapping also stays unchanged โ€” which is something you literally cannot do with --remove-section followed by --add-section. Obsessed. You can specify this option more than once.
Note โ€” you can use --rename-section and --update-section together to both update and rename a section from one command line. In that case, pass the original section name to --update-section, and the original and new section names to --rename-section. iykyk โœจ
  • --add-symbol name=[section:]value[,flags] โ€” adds a new symbol called name while copying the file. May be specified multiple times. If the section is given, the symbol gets associated with and is relative to that section; otherwise it's an ABS symbol. Specifying a section that doesn't exist = ๐Ÿ’€ fatal error. There is no check for the value, it'll just be taken as specified. Symbol flags can be given and not all flags will be meaningful for all object file formats. By default the symbol is global. The special flag before=othersym inserts the new symbol in front of the specified othersym, otherwise the symbol(s) get added at the end of the symbol table, in the order they appear.
  • --rename-section oldname=newname[,flags] โ€” renames a section from oldname to newname, optionally changing the section's flags to flags along the way โœจ The glow-up advantage over using a linker script for the rename: the output stays as an object file and doesn't become a linked executable. This option accepts the same set of flags as --set-section-flags.

This one is particularly helpful when the input format is binary, because that always creates a section called .data. So if, for example, you wanted a section called .rodata containing binary data instead, you could do:

objcopy -I binary -O <output_format> -B <architecture> \
 --rename-section .data=.rodata,alloc,load,readonly,data,contents \
 <input_binary_file> <output_object_file>
  • --long-section-names {enable,disable,keep} โ€” controls how long section names are handled when processing COFF and PE-COFF object formats ๐Ÿ‘‘ The default behaviour, keep, preserves long section names if any are present in the input file. enable and disable forcibly enable or disable the use of long section names in the output object; when disable is in effect, any long section names in the input object get truncated ๐Ÿ˜ญ The enable option will only emit long section names if any are present in the inputs โ€” mostly the same as keep, but it's left undefined whether enable might force the creation of an empty string table in the output file.
  • --change-leading-char โ€” some object file formats use special characters at the start of symbols, and the most common one is underscore, which compilers often slap before every symbol ๐Ÿ’… This option tells objcopy to change the leading character of every symbol when it converts between object file formats. If both formats use the same leading character, this option does nothing (no thoughts, head empty). Otherwise it'll add a character, remove a character, or change a character, as appropriate.
  • --remove-leading-char โ€” if the first character of a global symbol is a special symbol leading character used by the object file format, remove it โœ‚๏ธ The most common symbol leading character is underscore, so this option removes a leading underscore from all global symbols. Useful if you wanna link together objects of different file formats with different conventions for symbol names. This is different from --change-leading-char because it always changes the symbol name when appropriate, regardless of the object file format of the output file.
  • --reverse-bytes=num โ€” reverses the bytes in a section with output contents ๐Ÿ”„ A section's length must be evenly divisible by the value given in order for the swap to actually take place. Reversing happens before the interleaving is performed.

This is used typically in generating ROM images for problematic target systems. Like, on some target boards, the 32-bit words fetched from 8-bit ROMs get re-assembled in little-endian byte order regardless of the CPU byte order ๐Ÿ˜ตโ€๐Ÿ’ซ Depending on the programming model, the endianness of the ROM may need to be modified.

Picture a simple file with a section containing the following eight bytes: 12345678.

Using --reverse-bytes=2 for the above example, the bytes in the output file would be ordered 21436587.

Using --reverse-bytes=4 for the above example, the bytes in the output file would be ordered 43218765.

And by using --reverse-bytes=2 for the above example, followed by --reverse-bytes=4 on the output file, the bytes in the second output file would be ordered 34127856. Slay ๐ŸŽ€

  • --srec-len=ival โ€” meaningful only for srec output. Sets the maximum length of the Srecords being produced to ival. This length covers both address, data and crc fields.
  • --srec-forceS3 โ€” meaningful only for srec output. Avoids generation of S1/S2 records, creating S3-only record format ๐Ÿ”ฅ
  • --redefine-sym old=new โ€” changes the name of a symbol from old to new. Super useful when you're trying to link two things together, you have no source for them, and there are name collisions ๐Ÿ˜ญ
  • --redefine-syms=filename โ€” applies --redefine-sym to each symbol pair "old new" listed in the file filename. filename is simply a flat file, with one symbol pair per line. Line comments may be introduced by the hash character (#). This option may be given more than once.
  • --weaken โ€” changes all global symbols in the file to be weak ๐Ÿฆ‹ Useful when building an object that'll be linked against other objects using the -R option to the linker. This option is only effective when using an object file format that supports weak symbols.
  • --keep-symbols=filename โ€” applies --keep-symbol to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
  • --strip-symbols=filename โ€” applies --strip-symbol to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
  • --strip-unneeded-symbols=filename โ€” applies --strip-unneeded-symbol to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
  • --keep-global-symbols=filename โ€” applies --keep-global-symbol to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
  • --localize-symbols=filename โ€” applies --localize-symbol to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
  • --globalize-symbols=filename โ€” applies --globalize-symbol to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
Note โ€” this option cannot be used in conjunction with the -G or --keep-global-symbol options. Pick a lane bestie ๐Ÿ’€
  • --weaken-symbols=filename โ€” applies --weaken-symbol to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
  • --alt-machine-code=index โ€” if the output architecture has alternate machine codes, use the indexth code instead of the default one ๐Ÿงš This is useful in case a machine gets assigned an official code and the toolchain adopts the new code, but other applications still depend on the original code being used. For ELF based architectures, if the index alternative does not exist, then the value is treated as an absolute number to be stored in the e_machine field of the ELF header.
  • --writable-text โ€” marks the output text as writable ๐Ÿ‘‘ This option isn't meaningful for all object file formats.
  • --readonly-text โ€” makes the output text write protected ๐Ÿ”’ This option isn't meaningful for all object file formats.
  • --pure โ€” stamps the output file as demand paged โœจ. Lowkey only meaningful for some object file formats, so don't come crying if it does nothing on yours bestie.
  • --impure โ€” stamps the output file as impure ๐Ÿ™ˆ. Same deal, it's not meaningful for all object file formats.
  • --prefix-symbols=string โ€” takes every symbol in the output file and glues string onto the front of it ๐ŸŽ€.
  • --prefix-sections=string โ€” same energy but for section names: every section name in the output file gets string prefixed ๐Ÿ’….
  • --prefix-alloc-sections=string โ€” and this one prefixes the names of all allocated sections in the output file with string ๐Ÿ‘‘.
  • --add-gnu-debuglink=path-to-file โ€” makes a .gnu_debuglink section that holds a reference to path-to-file and drops it into the output file ๐Ÿ”ฅ. Heads up though: the file at path-to-file must exist. Part of the whole adding-the-.gnu_debuglink-section process is embedding a checksum of the debug info file's contents into that section.

So if the debug info file gets built in one location but is gonna be installed somewhere else later, do not use the path to the installed location โ€” the --add-gnu-debuglink option will fail because the installed file doesn't exist yet ๐Ÿ˜ญ. Instead, put the debug info file in the current directory and call --add-gnu-debuglink with no directory components at all, like this:

objcopy --add-gnu-debuglink=foo.debug

At debug time, the debugger will go looking for the separate debug info file in a set of known locations. That exact set changes depending on which distribution you're on, but it typically includes:

  • The same directory as the executable.
  • A sub-directory of the directory containing the executable called .debug.
  • A global debug directory such as /usr/lib/debug.

As long as the debug info file is installed into one of these locations before the debugger runs, everything should work correctly ๐Ÿ’–.

  • --keep-section-symbols โ€” when you're stripping a file (maybe with --strip-debug or --strip-unneeded), this keeps any symbols that specify section names, which would otherwise get stripped ๐Ÿซถ.
  • --keep-file-symbols โ€” same vibe, different icon: when stripping a file (again, maybe with --strip-debug or --strip-unneeded), retain any symbols specifying source file names, which would otherwise get stripped ๐ŸŒธ.
  • --only-keep-debug โ€” strips a file, removing the contents of any sections that --strip-debug wouldn't strip, while leaving the debugging sections intact. In ELF files, this preserves all note sections in the output โญ.

Note: the section headers of the stripped sections are preserved, including their sizes, but the contents of the section get discarded. The headers stay around so other tools can match up the debuginfo file with the real executable โ€” even if that executable has been relocated to a different address space ๐Ÿ‘€.

The whole intention here is that this option gets used together with --add-gnu-debuglink to create a two-part executable. One part is a stripped binary that takes up less space in RAM and in a distribution, and the second part is a debugging information file that's only needed if you actually want debugging abilities. The suggested procedure to build these files goes like this:

  1. Link the executable as normal. Assuming it's called foo thenโ€ฆ
  2. Run objcopy --only-keep-debug foo foo.dbg to make a file containing the debugging info.
  3. Run objcopy --strip-debug foo to make a stripped executable.
  4. Run objcopy --add-gnu-debuglink=foo.dbg foo to add a link to the debugging info into the stripped executable.

Note โ€” picking .dbg as the extension for the debug info file is completely arbitrary, bestie. Also the --only-keep-debug step is optional. You could instead do this:

  1. Link the executable as normal.
  2. Copy foo to foo.full.
  3. Run objcopy --strip-debug foo.
  4. Run objcopy --add-gnu-debuglink=foo.full foo.

i.e. the file pointed to by --add-gnu-debuglink can be the full executable. It does not have to be a file created by the --only-keep-debug switch ๐Ÿ’€.

Note โ€” this switch is only intended for use on fully linked files. It does not make sense to use it on object files where the debugging information may be incomplete. Besides, the gnu_debuglink feature currently only supports the presence of one filename containing debugging information โ€” not multiple filenames on a one-per-object-file basis.
  • --strip-dwo โ€” removes the contents of all DWARF .dwo sections, leaving the remaining debugging sections and all symbols intact ๐Ÿงš. This option is meant to be used by the compiler as part of the -gsplit-dwarf option, which splits debug information between the .o file and a separate .dwo file. The compiler generates all debug info in the same file, then uses --extract-dwo to copy the .dwo sections into the .dwo file, then uses --strip-dwo to remove those sections from the original .o file.
  • --extract-dwo โ€” extracts the contents of all DWARF .dwo sections. Peep the --strip-dwo option above for more info ๐Ÿ’œ.
  • --file-alignment num โ€” sets the file alignment. Sections in the file will always start at file offsets that are multiples of this number. Defaults to 512. [This option is specific to PE targets.]
  • --heap reserve
  • --heap reserve,commit โ€” specify how many bytes of memory to reserve (and optionally commit) to be used as the heap for this program. [This option is specific to PE targets.]
  • --image-base value โ€” use value as the base address of your program or dll. This is the lowest memory location that'll be used when your program or dll is loaded. To cut down on the need to relocate and to boost performance of your dlls, each one should have a unique base address and not overlap any other dlls ๐Ÿ‘‘. The default is 0x400000 for executables, and 0x10000000 for dlls. [This option is specific to PE targets.]
  • --section-alignment num โ€” [This option is specific to PE targets.]

Sets the section alignment field in the PE header โ€” if one is present in the binary. Sections in memory will always start at addresses that are a multiple of this number. Defaults to 0x1000.

Note โ€” if a section's LMA or VMA addresses are no longer aligned, and those addresses weren't set via the --set-section-lma or --set-section-vma options, and the file has been fully relocated, then a warning message will be issued ๐Ÿ˜ฌ. It's then up to you, the user, to decide if the LMA and VMA need updating.

  • --stack reserve
  • --stack reserve,commit โ€” specify the number of bytes of memory to reserve (and optionally commit) to be used as the stack for this program. [This option is specific to PE targets.]
  • --subsystem which
  • --subsystem which:major
  • --subsystem which:major.minor โ€” specifies the subsystem under which your program will execute. The legal values for which are native, windows, console, posix, efi-app, efi-bsd, efi-rtd, sal-rtd, and xbox โœจ. You can optionally set the subsystem version too. Numeric values are also accepted for which. [This option is specific to PE targets.]
  • --extract-symbol โ€” keeps the file's section flags and symbols but removes all section data. Specifically, this option:
    • Removes the contents of all sections.
    • Sets the size of every section to zero.
    • Sets the file's start address to zero.

This option is used to build a .sym file for a VxWorks kernel ๐ŸŽ€. It can also be a genuinely useful way of shrinking down the size of a --just-symbols linker input file.

  • --compress-debug-sections โ€” compresses DWARF debug sections using zlib with SHF_COMPRESSED from the ELF ABI ๐Ÿ”ฅ. Note โ€” if compression would actually make a section larger, then it isn't compressed. Electric.
  • --compress-debug-sections=none
  • --compress-debug-sections=zlib
  • --compress-debug-sections=zlib-gnu
  • --compress-debug-sections=zlib-gabi
  • --compress-debug-sections=zstd โ€” for ELF files, these options control how DWARF debug sections get compressed ๐Ÿฆ‹. --compress-debug-sections=none is equivalent to --decompress-debug-sections. --compress-debug-sections=zlib and --compress-debug-sections=zlib-gabi are equivalent to --compress-debug-sections. --compress-debug-sections=zlib-gnu compresses DWARF debug sections using the obsoleted zlib-gnu format โ€” the debug sections get renamed to begin with .zdebug. --compress-debug-sections=zstd compresses DWARF debug sections using zstd. Note โ€” if compression would actually make a section larger, then it is not compressed nor renamed ๐Ÿ’….
  • --decompress-debug-sections โ€” decompresses DWARF debug sections. For a .zdebug section, the original name is restored ๐ŸŒธ.
  • --elf-stt-common=yes
  • --elf-stt-common=no โ€” for ELF files, these options control whether common symbols should be converted to the "STT_COMMON" or "STT_OBJECT" type. --elf-stt-common=yes converts the common symbol type to "STT_COMMON". --elf-stt-common=no converts the common symbol type to "STT_OBJECT" โญ.
  • --merge-notes
  • --no-merge-notes โ€” for ELF files, attempt (or do not attempt) to reduce the size of any SHT_NOTE type sections by removing duplicate notes ๐Ÿ‘€.
  • -V
  • --version โ€” shows the version number of objcopy ๐Ÿ’–.
  • --verilog-data-width=bytes โ€” for Verilog output, this option controls how many bytes get converted for each output data element. The input target controls the endianness of the conversion ๐Ÿงš.
  • -v
  • --verbose โ€” verbose output: lists all object files modified. In the case of archives, objcopy -V lists all members of the archive ๐ŸŒˆ.
  • --help โ€” shows a summary of the options to objcopy ๐Ÿซถ.
  • --info โ€” displays a list showing all architectures and object formats available โœจ.
  • @file โ€” reads command-line options from file. The options that get read are inserted in place of the original @file option. If file doesn't exist, or can't be read, then the option is treated literally, and not removed ๐Ÿ™ˆ.

Options in file are separated by whitespace. A whitespace character can be included in an option by surrounding the entire option in either single or double quotes. Any character (including a backslash) can be included by prefixing the character you want to include with a backslash ๐Ÿ’…. The file may itself contain additional @file options; any such options get processed recursively, it's giving nesting doll energy ๐ŸŽ€.

๐ŸŒˆ SEE ALSO ๐Ÿ’ซ

okay so if you wanna go deeper (and bestie, you know you do), go hang out with these:

  • ld(1) โ€” the linker bestie, the one who actually puts all your object files together into something that runs ๐Ÿ‘‘
  • objdump(1) โ€” the nosy queen who reads object files back to you, the mirror to objcopy's makeover energy, if you will ๐Ÿชž
  • and the Info entries for binutils โ€” like the extended director's cut, all the lore in one place, iykyk ๐Ÿ“šโœจ

Copyright (c) 1991-2026 Free Software Foundation, Inc.

okay so legally speaking, here's the whole vibe ๐Ÿ’…:

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation โ€” with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". ๐Ÿซถ

like, yes you can share it, yes you can remix it, just keep the license with it, periodt. no gatekeeping on documentation, that's the energy โœจ๐Ÿ“–


and that's the whole page, bestie!! we did it!! ๐Ÿฅณ you just read the entire objcopy(1) manual and honestly? iconic. main character energy fr fr ๐Ÿ‘‘

this was binutils-2.47, dated 2026-09-12 โ€” go forth and copy those objects, babe ๐Ÿ’–๐Ÿ’…๐Ÿฆ‹

๐Ÿ“ฆ where this page comes from