Marty E. Plummer has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/35083 )
Change subject: arch/ppc64: add -mregnames to assembler directives ......................................................................
arch/ppc64: add -mregnames to assembler directives
I order to avoid spurious errors `Error: unsupported relocation against rN` without a massive asm.h header #define'ing rN to N add these flags.
Change-Id: Ib3bef76c4449a2edc7b5874c6bda7df9007afd37 Signed-off-by: Marty E. Plummer hanetzer@startmail.com --- M src/arch/ppc64/Makefile.inc 1 file changed, 2 insertions(+), 2 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/83/35083/1
diff --git a/src/arch/ppc64/Makefile.inc b/src/arch/ppc64/Makefile.inc index bb9c63dd..e9997f7 100644 --- a/src/arch/ppc64/Makefile.inc +++ b/src/arch/ppc64/Makefile.inc @@ -16,8 +16,8 @@ ## ################################################################################
-ppc64_flags = -I$(src)/arch/ppc64/ -mbig-endian -ppc64_asm_flags = +ppc64_flags = -I$(src)/arch/ppc64/ -mbig-endian -Wa,-mregnames +ppc64_asm_flags = -mregnames
################################################################################ ## Take care of subdirectories
Hello ron minnich, Patrick Georgi, Martin Roth,
I'd like you to reexamine a change. Please visit
https://review.coreboot.org/c/coreboot/+/35083
to look at the new patch set (#2).
Change subject: arch/ppc64: add -mregnames to assembler directives ......................................................................
arch/ppc64: add -mregnames to assembler directives
In order to avoid spurious errors `Error: unsupported relocation against rN` without a massive asm.h header #define'ing rN to N add these flags.
Change-Id: Ib3bef76c4449a2edc7b5874c6bda7df9007afd37 Signed-off-by: Marty E. Plummer hanetzer@startmail.com --- M src/arch/ppc64/Makefile.inc 1 file changed, 2 insertions(+), 2 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/83/35083/2
Timothy Pearson has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35083 )
Change subject: arch/ppc64: add -mregnames to assembler directives ......................................................................
Patch Set 3:
Can you elaborate a bit more on where / why the other style register names are being emitted and what chunk(s) of build system / compiler / etc. we are essentially forcing compatibility with?
Marty E. Plummer has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35083 )
Change subject: arch/ppc64: add -mregnames to assembler directives ......................................................................
Patch Set 3:
Patch Set 3:
Can you elaborate a bit more on where / why the other style register names are being emitted and what chunk(s) of build system / compiler / etc. we are essentially forcing compatibility with?
Compatibility-wise is a bit tricky. in the binutils-gdb repository, gas/ChangeLog-9697 mentions two changes which impact -mregnames in 1996, which both predate the existance of the git repo as far as I can tell. bintutils/gdb/gas/config/tc-ppc.c includes the named registers in the initial commit 252b5132c753830d5fd56823373aed85f2a0db63, which is made slightly more robust in 7e0de605cbacbbbb2531bb70506c0843aea13111 (previously the assembler would accept 'addi %f4,%cr3,%r31`, presumably interpreting that as 'addi 4, 3, 31' without context. This was in 2017. These are the only two commits in the git history that touch that particular bit of code, so presumably any 'modern' version would work.
Marty E. Plummer has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35083 )
Change subject: arch/ppc64: add -mregnames to assembler directives ......................................................................
Patch Set 3:
Patch Set 3:
Patch Set 3:
Can you elaborate a bit more on where / why the other style register names are being emitted and what chunk(s) of build system / compiler / etc. we are essentially forcing compatibility with?
Compatibility-wise is a bit tricky. in the binutils-gdb repository, gas/ChangeLog-9697 mentions two changes which impact -mregnames in 1996, which both predate the existance of the git repo as far as I can tell. bintutils/gdb/gas/config/tc-ppc.c includes the named registers in the initial commit 252b5132c753830d5fd56823373aed85f2a0db63, which is made slightly more robust in 7e0de605cbacbbbb2531bb70506c0843aea13111 (previously the assembler would accept 'addi %f4,%cr3,%r31`, presumably interpreting that as 'addi 4, 3, 31' without context. This was in 2017. These are the only two commits in the git history that touch that particular bit of code, so presumably any 'modern' version would work.
Ah, misread. Well, mregnames was added in commit 159e6ef88fe32c13a6a9d7485efa83ab6e47be9a, which is still a commit from 1996, so should be available in general on any 'modern' toolchain
Marty E. Plummer has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/35083 )
Change subject: arch/ppc64: add -mregnames to assembler directives ......................................................................
Patch Set 3:
Patch Set 3:
Can you elaborate a bit more on where / why the other style register names are being emitted and what chunk(s) of build system / compiler / etc. we are essentially forcing compatibility with?
Regarding register emission, here's an experiment.
Take https://www.ibm.com/developerworks/library/l-ppc/hello-ppc64.s straight from ibm, assemble it using the toolchain built by coreboot. No problems. Disassemble the resultant object file, and objdump will use the named registers instead of the numeric ones. Make a copy of hellp-ppc64.s and edit it to use the named registers as presented in the disassembly, and attempt to assemble that. You'll get about 14 'Error: unsupported relocation against rN' errors. Add the -mregnames arg and try again, no problem. And at least on my machine the resultant hello-ppc64.o binaries have the same md5sum.
Perhaps there is a better place to stick this `-mregnames` flag but atm this is what I've came up with.
-
Marty E. Plummer (Code Review) -
Timothy Pearson (Code Review)