From: SourceForge.net <no...@so...> - 2008-08-25 01:09:17
|
Bugs item #2067837, was opened at 2008-08-22 09:47 Message generated for change (Comment added) made by hpa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2067837&group_id=6208 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Assembler Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: A Fog (agnerfog) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong addresses on public symbols Initial Comment: Assembling the attached file produces an object file where the addresses of public symbols L1, L2, L3 are wrong by an offset of 2. To reproduce: nasm -f win64 -o nasmerr1.obj nasmerr1.asm then dump or disassemble. The correct addresses of L1, L2, L3 should be 4, 5, 6. The actual addresses are 6, 7, 8. Nasm ver. 2.03.01 ---------------------------------------------------------------------- Comment By: H. Peter Anvin (hpa) Date: 2008-08-24 18:09 Message: Logged In: YES user_id=58697 Originator: NO This item has been resolved; the fix has been checked into git (http://repo.or.cz/w/nasm.git) and will be in the next release. You can usually also obtain a nightly snapshot at ftp://ftp.zytor.com/pub/nasm/snapshots/; the snapshot robot usually runs some time between 09:00 and 10:30 UTC. ---------------------------------------------------------------------- Comment By: H. Peter Anvin (hpa) Date: 2008-08-24 18:06 Message: Logged In: YES user_id=58697 Originator: NO The 66 0F prefix is encoded in the VEX prefix, so, no, it shouldn't be output. ---------------------------------------------------------------------- Comment By: Chuck Crayne (ccrayne) Date: 2008-08-24 17:58 Message: Logged In: YES user_id=73628 Originator: NO > Hmmm... what's the "+2" on line 978 of assemble.c doing for us? It's allowing space for the VEX prefix, and, in this case, it is the correct value. I'm not very good at reading the avx encodings yet, but it seems to me that the correct result should be: "C5 E9 66 0F 58 CB", which is six bytes long, and matches the calculated size. However what is actually generated is "C5 E9 58 CB", which accounts for the incorrect offsets. I am not sure where the "66 0F" bytes are getting lost, but I suspect "insns.pl". ---------------------------------------------------------------------- Comment By: H. Peter Anvin (hpa) Date: 2008-08-24 17:26 Message: Logged In: YES user_id=58697 Originator: NO The adds on lines 978 and 985 are bogus. The proper length adds are done on lines 1132 and 1134. So lines 978 and 985 should be deleted. ---------------------------------------------------------------------- Comment By: nasm64developer (nasm64developer) Date: 2008-08-24 17:21 Message: Logged In: YES user_id=804543 Originator: NO > What's "right" there? In case of 026[0-3] and 0270 calcsize() uses +2, while gencode() uses +2 or +3, depending on whether the short or long AVX encoding gets picked. As a result you will get phase errors whenever 3-byte AVX gets picked -- fix calcsize() to match gencode(), and the problems should disappear. ---------------------------------------------------------------------- Comment By: Frank Kotler (fbkotler) Date: 2008-08-24 15:21 Message: Logged In: YES user_id=68913 Originator: NO Hmmm... what's the "+2" on line 978 of assemble.c doing for us? Commenting it out makes this go away. What's "right" there? Best, Frank ---------------------------------------------------------------------- Comment By: Frank Kotler (fbkotler) Date: 2008-08-24 14:53 Message: Logged In: YES user_id=68913 Originator: NO Excellent! Thank you! Back to our bug... is it my imagination, or does this error only occur on AVX instructions (sandybridge)? I haven't checked extensively, but at least *some* other instructions in that spot seem to give correct results, and *some* other AVX instructions exhibit the problem... That's as far as I've gotten (I'm *way* over my head here!) Best, Frank ---------------------------------------------------------------------- Comment By: A Fog (agnerfog) Date: 2008-08-23 22:54 Message: Logged In: YES user_id=1052480 Originator: YES fbkotler wrote: The only tool I've got that'll "dump" it is "objconv" (Very sweet, Sir! Thank you! ...any chance of a "-fnasm" switch?). You're lucky. I just added a -fnasm switch two days ago! ---------------------------------------------------------------------- Comment By: Frank Kotler (fbkotler) Date: 2008-08-23 11:09 Message: Logged In: YES user_id=68913 Originator: NO Hello Mr. Fog, Delighted to see you taking an interest in Nasm! I can confirm this problem. The only tool I've got that'll "dump" it is "objconv" (Very sweet, Sir! Thank you! ...any chance of a "-fnasm" switch?). I can also see 6, 7, 8 in a raw hexdump of the .obj. (note that the addresses in the code itself are okay) Seems like a fairly serious bug! Best, Frank ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=106208&aid=2067837&group_id=6208 |