Re: Ok, somebody give me a clue.

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> David Kastrup <address@hidden> writes:
>
>> For debugging purposes, I have been using the following:
>>
>> struct trbuf { void* pc; int value; } trbuf[256];
>> unsigned char trptr;
>> #define RECORD_INPUT do { __label__ woozle; \
>>   woozle: trbuf[trptr++] = (struct trbuf)                            \
>
> Does [trptr++%256] give better results ?

No, I already did that.  I also increased the amount of pure storage
size since obviously that macro gets compiled in a lot.  No go.  I had
a version temporarily where I initialized the data, causing it to end
up in the .data segment, seemingly a nono.  But I have checked that it
is now correctly in .bss.

I also tried replacing the code by something without the
constructor-style task.  No luck.

>> And then whereever I change interrupt_input_blocked, I also call
>> RECORD_INPUT.  This causes Emacs to crash in unrelated spaces.  I
>> have crosschecked the compiled code, and it does the correct thing:
>> no data type overflow problems or something.

Bah.  I have now tracked this down.  The following causes crashes
already with SIGSEGV at some unrelated place.

#define RECORD_INPUT do { __label__ woozle; woozle: ; } while (0)

If I instead use

#define RECORD_INPUT do { ; } while (0)

it works.  So either gcc is broken with regard to local labels, or it
produces something from them which confuses the dumper.

Does anybody have a good clue whether this is just to be considered an
Emacs internal problem?

I'll probably get at the current address by some other means as well,
but it might be something which one ought to report, unless it is just
our dumper.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum