> -----Original Message----- > From: Maciej W. Rozycki [mailto:ma...@linux-mips.org] > Sent: Thursday, April 16, 2015 2:23 PM > To: Petar Jovanovic > Cc: Moore, Catherine; 'Matthew Fortune'; gcc-patches@gcc.gnu.org > Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro > > On Thu, 16 Apr 2015, Petar Jovanovic wrote: > > > > There isn't any need to execute a large testcase. Instead, try > > > adding a > > short version of your test to the directory gcc/testsuite/gcc.target/mips. > > > There are examples of other tests there they check for specific > > > assembler > > sequences by using scan-assembler. See umips-swp-1.c (and others) for a > > specific example of how to do this. > > > Let me know if you need additional help. > > > Thanks, > > > Catherine > > > > Hi Catherine, > > > > Sorry for late response, I have missed to follow up on this. > > IIUC, scan-assembler will scan assembly file generated from a test file. > > This particular change will - on the other hand - modify crtend.o and > > thus init section. Is there a 'scan-assembler' functionality over a > > final linked executable, as that would actually test the change? > Hi Petar, It looks like I answered a little too quickly the first time around. I'm sorry. In any case, Maciej is correct. I think a link-time test should do it. Thanks, Catherine
> You'd need `objdump' for doing that and there is no ready-to-use solution > within the GCC test suite available, you'd have to cook something up > yourself, perhaps starting with `[find_binutils_prog objdump]'. > > Another solution might be using an auxiliary linker script (`-Wl,-T,...' > or maybe just an implicit linker script will do; see the LD manual for > details) to place the sections the jump is made between apart manually at > addresses appropriate for JAL to fail. They span does not have to be large -- > when placed correctly, even `JAL .' can jump to the wrong place, which is > what LD is supposed to catch as a relocation error -- so a test executable > successfully linked with your correction in place won't be large, it doesn't > have to take more than 2 virtual pages. > > The downside of the latter solution are possible portability issues with the > linker script. You won't have to run your executable AFAICT from glibc BZ > #17601 as you'll get a link error if a jump target is out of range. So you > could > make it a mere link test, no need to run it. > > Maciej
