maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/tools/llvm-objcopy/binary-paddr.test

46 lines
1.2 KiB
Plaintext
Raw Normal View History

Reland "[llvm][llvm-objcopy] Added support for outputting to binary in llvm-objcopy" This change adds the "-O binary" flag which directs llvm-objcopy to output the object file to the same format as GNU objcopy does when given the flag "-O binary". This was done by splitting the Object class into two subclasses ObjectELF and ObjectBianry which each output a different format but relay on the same code to read in the Object in Object. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D34480 llvm-svn: 310127
2017-08-05 05:09:26 +08:00
# RUN: yaml2obj %s -o %t
# RUN: llvm-objcopy -O binary %t %t2
# RUN: od -t x2 %t2 | FileCheck %s
# RUN: wc -c < %t2 | FileCheck %s --check-prefix=SIZE
!ELF
FileHeader:
Class: ELFCLASS64
Data: ELFDATA2LSB
Type: ET_EXEC
Machine: EM_X86_64
Sections:
- Name: .text
Type: SHT_PROGBITS
Flags: [ SHF_ALLOC, SHF_EXECINSTR ]
[llvm-objcopy] Use physical instead of virtual address when aligning and placing sections in binary For sections with different virtual and physical addresses, alignment and placement in the output binary should be based on the physical address. Ran into this problem with a bare metal ARM project where llvm-objcopy added a lot of zero-padding before the .data section that had differing addresses. GNU objcopy did not add the padding, and after this fix, neither does llvm-objcopy. Update a test case so a section has different physical and virtual addresses. Fixes B35708 Authored By: Owen Shaw (owenpshaw) Differential Revision: https://reviews.llvm.org/D41619 llvm-svn: 323144
2018-01-23 03:27:30 +08:00
Address: 0x1000
Reland "[llvm][llvm-objcopy] Added support for outputting to binary in llvm-objcopy" This change adds the "-O binary" flag which directs llvm-objcopy to output the object file to the same format as GNU objcopy does when given the flag "-O binary". This was done by splitting the Object class into two subclasses ObjectELF and ObjectBianry which each output a different format but relay on the same code to read in the Object in Object. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D34480 llvm-svn: 310127
2017-08-05 05:09:26 +08:00
AddressAlign: 0x0000000000001000
Content: "c3c3c3c3"
- Name: .data
Type: SHT_PROGBITS
[llvm-objcopy] Use physical instead of virtual address when aligning and placing sections in binary For sections with different virtual and physical addresses, alignment and placement in the output binary should be based on the physical address. Ran into this problem with a bare metal ARM project where llvm-objcopy added a lot of zero-padding before the .data section that had differing addresses. GNU objcopy did not add the padding, and after this fix, neither does llvm-objcopy. Update a test case so a section has different physical and virtual addresses. Fixes B35708 Authored By: Owen Shaw (owenpshaw) Differential Revision: https://reviews.llvm.org/D41619 llvm-svn: 323144
2018-01-23 03:27:30 +08:00
Flags: [ SHF_ALLOC ]
Address: 0x2000
Reland "[llvm][llvm-objcopy] Added support for outputting to binary in llvm-objcopy" This change adds the "-O binary" flag which directs llvm-objcopy to output the object file to the same format as GNU objcopy does when given the flag "-O binary". This was done by splitting the Object class into two subclasses ObjectELF and ObjectBianry which each output a different format but relay on the same code to read in the Object in Object. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D34480 llvm-svn: 310127
2017-08-05 05:09:26 +08:00
AddressAlign: 0x0000000000001000
Content: "3232"
ProgramHeaders:
- Type: PT_LOAD
Flags: [ PF_X, PF_R ]
[llvm-objcopy] Use physical instead of virtual address when aligning and placing sections in binary For sections with different virtual and physical addresses, alignment and placement in the output binary should be based on the physical address. Ran into this problem with a bare metal ARM project where llvm-objcopy added a lot of zero-padding before the .data section that had differing addresses. GNU objcopy did not add the padding, and after this fix, neither does llvm-objcopy. Update a test case so a section has different physical and virtual addresses. Fixes B35708 Authored By: Owen Shaw (owenpshaw) Differential Revision: https://reviews.llvm.org/D41619 llvm-svn: 323144
2018-01-23 03:27:30 +08:00
VAddr: 0x1000
PAddr: 0x1000
Align: 0x1000
Reland "[llvm][llvm-objcopy] Added support for outputting to binary in llvm-objcopy" This change adds the "-O binary" flag which directs llvm-objcopy to output the object file to the same format as GNU objcopy does when given the flag "-O binary". This was done by splitting the Object class into two subclasses ObjectELF and ObjectBianry which each output a different format but relay on the same code to read in the Object in Object. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D34480 llvm-svn: 310127
2017-08-05 05:09:26 +08:00
Sections:
- Section: .text
- Type: PT_LOAD
[llvm-objcopy] Use physical instead of virtual address when aligning and placing sections in binary For sections with different virtual and physical addresses, alignment and placement in the output binary should be based on the physical address. Ran into this problem with a bare metal ARM project where llvm-objcopy added a lot of zero-padding before the .data section that had differing addresses. GNU objcopy did not add the padding, and after this fix, neither does llvm-objcopy. Update a test case so a section has different physical and virtual addresses. Fixes B35708 Authored By: Owen Shaw (owenpshaw) Differential Revision: https://reviews.llvm.org/D41619 llvm-svn: 323144
2018-01-23 03:27:30 +08:00
Flags: [ PF_R, PF_W ]
VAddr: 0x2000
PAddr: 0x4000
Align: 0x1000
Reland "[llvm][llvm-objcopy] Added support for outputting to binary in llvm-objcopy" This change adds the "-O binary" flag which directs llvm-objcopy to output the object file to the same format as GNU objcopy does when given the flag "-O binary". This was done by splitting the Object class into two subclasses ObjectELF and ObjectBianry which each output a different format but relay on the same code to read in the Object in Object. Patch by Jake Ehrlich Differential Revision: https://reviews.llvm.org/D34480 llvm-svn: 310127
2017-08-05 05:09:26 +08:00
Sections:
- Section: .data
# CHECK: 0000000 c3c3 c3c3 0000 0000 0000 0000 0000 0000
# CHECK-NEXT: 0000020 0000 0000 0000 0000 0000 0000 0000 0000
# CHECK-NEXT: *
[llvm-objcopy] Use physical instead of virtual address when aligning and placing sections in binary For sections with different virtual and physical addresses, alignment and placement in the output binary should be based on the physical address. Ran into this problem with a bare metal ARM project where llvm-objcopy added a lot of zero-padding before the .data section that had differing addresses. GNU objcopy did not add the padding, and after this fix, neither does llvm-objcopy. Update a test case so a section has different physical and virtual addresses. Fixes B35708 Authored By: Owen Shaw (owenpshaw) Differential Revision: https://reviews.llvm.org/D41619 llvm-svn: 323144
2018-01-23 03:27:30 +08:00
# CHECK-NEXT: 0030000 3232
# SIZE: 12290