[Converted from Gnats 1503] This code has a problem: hppa_frame_find_saved_regs ... /* A std has explicit post_modify_forms. */ else if ((inst & 0xfc00000c0) == 0x70000008) frame_saved_regs[reg] = get_frame_base (frame_info); else ... The problem is that "0xfc00000c0" is 9 hex digits long. gcc 3.3.2 throws a warning (but gcc 3.2-7-rh does not) and the code turns into an "if (0)". This code was introduced in hppa-tdep.c version 1.1.1.10 on 1999-08-31. Release: gdb 6.0 Environment: target = native, host = hppa2.0-hp-hpux11.11 How-To-Repeat: That is tough. It doesn't happen with HP ansi c and HP aCC on my test system, using a gcov'ed version of gdb on the whole test suite.
Fix: Don't just change the instruction. That "if" test is way suspicious. There are two forms of std, and it handles only one form. It doesn't handle non-zero immediate displacemnts. The code in the "else" actually probably does a better job. Someone who knows their way around pa-risc instruction set and the ABI has to look at this. That might be me, in the future. PA-RISC instruction set: http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,2533,00.html page 7-136 (page 138 in chapter 7 of the PDF)
The extra digit was fixed in this commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5613269142b3d02fb227db9855bfda034fb261de But apparently there is more to do: (In reply to Michael Elizabeth Chastain from comment #1) > Fix: > Don't just change the instruction. That "if" test is way suspicious. There > are two forms of std, and it handles only one form. It doesn't handle > non-zero immediate displacemnts. The code in the "else" actually probably > does a better job.