[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: backtrace support
From: |
Marco Gerards |
Subject: |
Re: backtrace support |
Date: |
Wed, 31 Aug 2005 21:01:30 +0200 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) |
Vincent Guffens <address@hidden> writes:
>> I have the idea that another array for the symbols is not required. I
>> think we can use one common table. The symbol name and symbol address
>> are already in there. The hard thing is would getting the size,
>> perhaps we could leave that open and fill it in with a function, or
>> can we use a ld/gcc feature to do that? This will make the backtrace
>> code simpler and it saves memory. Do you think that is somehow
>> possible?
>
> This is true, another list of symbols is not required for this
> backtrace support but it makes the implementation a lot less
> intrusive. It would be possible to use some #ifdef here and there
> around the structures that are used already to add a field for the
> symbol size but it would not be very nice. If you turn the debug flag
> off, the code comes back to the original so I thought it would not be
> a problem.
It won't be that many ifdefs. I think that would be better than yet
another table.
> However, I found using a simple example that using -O2 still allows
> for using the frame pointer. This is to be verified but if it turns to
> be usable, than maybe using the --enable-debug will be less a problem
> and more popular so it would then be wise not to have the kernel
> symbol list twice. What do you think ?
Right, I think -O2 is not a problem if you do not show line numbers.
But if you show line numbers -O2 is not always accurate AFAIK because
gcc can reorder lines.
> To correct the rest, I think I will read the GCS in detail.
Cool!
Thanks,
Marco