segv with gas using gcc 3.2

Linux-ia64 Robert K Gjertsen 3 participants 3 messages Jan 29, 2003 – Jan 30, 2003

Share & tools

Robert K Gjertsen

author

2003-01-29 15:21 UTC #0 lore raw

This is a multipart message in MIME format.
--=_alternative 0033359286256CBD_Content-Type: text/plain; charset="us-ascii"

I'm seeing gas yak/segv on some assembly code that we use
to avoid pulling extraneous instructions into the
instruction cache (avoid debugging code when debugging is turned off). This used to work with gcc 2.96 but now dies with gcc 3.2
when optimizations are turned on (-O or higher). I'm trying to reduce this to a smaller and manageable case and also figure out whether I'm doing something ill-advised given that we are making
some assumptions on how the code is ordered in the remote section (works OK on i386 with gcc 3.2).
Just seeing if someone may have some insight on my example below.

Thanks,

--Rob

I use something like the following where the
assembly code before and after is usually a gcc asm macro for convenience (and this isn't all bundled together in a gcc asm statement like you see in spinlock.h with read_lock ... perhaps it has to be done that way with IA64),
and this is done numerous times in a particular file.

br.cond.sptk.few 2f
".section .text.trace,"ax
2:

# various instructions for my debugging/tracing code

br.cond.sptk.many 1f
.previous
1:

--=_alternative 0033359286256CBD_Content-Type: text/html; charset="us-ascii"

I'm seeing gas yak/segv on some assembly code that we use to avoid pulling extraneous instructions into the instruction cache (avoid debugging code when debugging is turned off). This used to work with gcc 2.96 but now dies with gcc 3.2 when optimizations are turned on (-O or higher). I'm trying to reduce this to a smaller and manageable case and also figure out whether I'm doing something ill-advised given that we are making some assumptions on how the code is ordered in the remote section (works OK on i386 with gcc 3.2).
 Just seeing if someone may have some insight on my example below. 
 Thanks,
 
 --Rob
 
 I use something like the following where the
 assembly code before and after is usually a gcc asm macro for convenience (and this isn't all bundled together in a gcc asm statement like you see in spinlock.h with read_lock ... perhaps it has to be done that way with IA64), and this is done numerous times in a particular file. 
 
 br.cond.sptk.few 2f 
".section .text.trace,"ax 
2:      
                       # various instructions for my debugging/tracing code
 
 br.cond.sptk.many 1f 
.previous 
1:
 
--=_alternative 0033359286256CBD_=--

David Mosberger

2003-01-29 17:12 UTC #1 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Robert K Gjertsen

Rob> I'm seeing gas yak/segv on some assembly code that we use to Rob> avoid pulling extraneous instructions into the instruction Rob> cache (avoid debugging code when debugging is turned off). Rob> This used to work with gcc 2.96 but now dies with gcc 3.2 when Rob> optimizations are turned on (-O or higher). I'm trying to Rob> reduce this to a smaller and manageable case and also figure Rob> out whether I'm doing something ill-advised given that we are Rob> making some assumptions on how the code is ordered in the Rob> remote section (works OK on i386 with gcc 3.2). Just seeing if Rob> someone may have some insight on my example below.

Perhaps the block-reordering is causing the problems for you? Might want to try -fno-reorder-blocks.

A general comment: I'd highly discourage to switch sections within a procedure. The problem is that the unwind info will be all wrong otherwise.

	--david

Jim Wilson

2003-01-30 16:08 UTC #2 lore raw

In reply to Robert K Gjertsen

It isn't clear to me what you are doing, since you mention problems with compiler optimization, but then state that you are using asm macros instead of gcc extended asm statements. You can't use asm macros in C code, so I don't understand what you are trying to say.

Gcc has support for automatically moving rarely used sections of code out of line. You can use __builtin_expect in a condition to indicate whether it is expected to be true or false. When gcc sees that a section of code is not expected to be executed, then it tries to move it someplace out of the way. This happens in the block reordering pass. This might be a better solution that what you are doing now. This is used in various places if you want to see examples. I think it is used in the kernel and glibc. There is also a little info in the gcc documentation.

On IA-64, changing sections in the middle of the function is a very bad idea. In addition to the unwind problems that David mentioned, you will also get bad insn bundling (unnecessary nops and stop bits). You may also get bad debug info. I think the IA-64 assembler should emit an error if someone switches sections in the middle of a function, but I never got a chance to try to implement that.

Jim