But I'm reaching out to you here as I was wondering if it is a bug in gas (unlikely, but it is a change in behavior for sure).
I found that even older 2.32 are ok.
2.32-7ubuntu4 - ok
2.32.51.20190905-0ubuntu1 - fails.
I was wondering and hoping you could help me on three things:
1. was the change to no more build that assembly intentional and could one maybe link to a commit for that?
2. if the change was intentional is there a best practice how the code should be modified to work again?
3. I was checking the behavior on push/pop %fs/gs and it confused me so I wonder if the current state is correct (see attachment and below).
For #3 some details:
Summary D vs E:
- no suffix
=> works equally in both releases
=> same opcodes in all .code segments
- suffix "w"
=> works equally in both releases
=> opcodes in .code32/.code64 differ from .code16 (660f..)
=> .code16 matches the non-suffix opcodes (0f..)
- suffix "l"
=> failures in Disco, works in Eoan
=> .code16 opcodes match the non-.code16 of the "w" suffix (660f..)
=> .code32/.code64 are back to the base opcode (0f..)
=> If I remove the failing .code64 from disco then .code16/.code32 is the same as in Eoan
- suffix "q"
=> different failures in Disco and Eoan
=> in Disco .code16/.code32 fails
=> in Disco .code64 generates the basic opcode (0f..)
=> in Eoan all three .code segments fail
I wonder if all of that is correct?
P.S. I can break this up into multiple bugs if you tell me which section you want to discuss separately.
P.P.S. I have asked upstream IPXE for feedback for (a pure gut feeling) change, but there was no response yet (http://lists.ipxe.org/pipermail/ipxe-devel/2019-September/006763.html)
Hi,
I have found that with recent binutils ipxe was no more compiling.
It broke on a section doing essentially (simplified) doing:
.code64
pushq %gs
pushq %fs
popq %gs
popq %fs
The fail I got was like:
push.S:2: Error: unsupported instruction `push'
push.S:3: Error: unsupported instruction `push'
push.S:4: Error: unsupported instruction `pop'
push.S:5: Error: unsupported instruction `pop'
There is more about that in Ubuntu bug https:/ /bugs.launchpad .net/ubuntu/ +source/ binutils/ +bug/1843394
But I'm reaching out to you here as I was wondering if it is a bug in gas (unlikely, but it is a change in behavior for sure).
I found that even older 2.32 are ok. 20190905- 0ubuntu1 - fails.
2.32-7ubuntu4 - ok
2.32.51.
I was wondering and hoping you could help me on three things:
1. was the change to no more build that assembly intentional and could one maybe link to a commit for that?
2. if the change was intentional is there a best practice how the code should be modified to work again?
3. I was checking the behavior on push/pop %fs/gs and it confused me so I wonder if the current state is correct (see attachment and below).
For #3 some details:
Summary D vs E:
- no suffix
=> works equally in both releases
=> same opcodes in all .code segments
- suffix "w"
=> works equally in both releases
=> opcodes in .code32/.code64 differ from .code16 (660f..)
=> .code16 matches the non-suffix opcodes (0f..)
- suffix "l"
=> failures in Disco, works in Eoan
=> .code16 opcodes match the non-.code16 of the "w" suffix (660f..)
=> .code32/.code64 are back to the base opcode (0f..)
=> If I remove the failing .code64 from disco then .code16/.code32 is the same as in Eoan
- suffix "q"
=> different failures in Disco and Eoan
=> in Disco .code16/.code32 fails
=> in Disco .code64 generates the basic opcode (0f..)
=> in Eoan all three .code segments fail
I wonder if all of that is correct?
P.S. I can break this up into multiple bugs if you tell me which section you want to discuss separately. lists.ipxe. org/pipermail/ ipxe-devel/ 2019-September/ 006763. html)
P.P.S. I have asked upstream IPXE for feedback for (a pure gut feeling) change, but there was no response yet (http://