Ok, somebody give me a clue.

Ok, somebody give me a clue.

[David Kastrup]

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)				\
			    { &&woozle, interrupt_input_blocked}; } while(0)

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.

So it is obvious that the problem is elsewhere, likely that the data
structures I use above confuse the garbage collector.  What kind of
data structures are allowed, and how can I hide data structures that
would confuse it from the garbarge collector?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ok, somebody give me a clue.

[Kim F. Storm]

David Kastrup <dak@gnu.org> 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 ?

> 			    { &&woozle, interrupt_input_blocked}; } while(0)
>
> 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.
>
> So it is obvious that the problem is elsewhere, likely that the data
> structures I use above confuse the garbage collector.  What kind of
> data structures are allowed, and how can I hide data structures that
> would confuse it from the garbarge collector?
>
> -- 
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Ok, somebody give me a clue.

[Andreas Schwab]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> 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 ?

trptr is unsigned char, so won't ever be bigger than 255.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Ok, somebody give me a clue.

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> David Kastrup <dak@gnu.org> 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 ?
>
> trptr is unsigned char, so won't ever be bigger than 255.

Type promotion can lead to strange effects.  While trptr++ seems like
a safe bet, I would not trust ++trptr...

Anyway, this apparently is a compiler or a dumper problem with the
local label.  I have to get at the current address with a different
method, probably inline assembly.  Pity.

Or construct a non-local label name from __LINE__.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Ok, somebody give me a clue.

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> 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

Re: Ok, somebody give me a clue.

[Richard Stallman]

    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.

The way to debug a problem like that is by looking at the assembler
code and seeing if it corresponds correctly to the source.

It is important to do this, because if GCC has a bug, we need to fix
it.  However, is there a later GCC you could try?  Maybe the bug is
fixed already.