[uClibc] mips dynamic section marked RWE

David Daney ddaney at avtrex.com
Fri Nov 12 01:22:10 UTC 2004


Erik Andersen wrote:
> On Thu Nov 11, 2004 at 08:15:13PM +0100, Peter S. Mazinger wrote:
> 
>>On Thu, 11 Nov 2004, Erik Andersen wrote:
>>
>>
>>>On Thu Nov 11, 2004 at 06:42:18PM +0100, Peter S. Mazinger wrote:
>>>
>>>>Hello!
>>>>
>>>>Does anyone have an idea why the dynamic section on mips[el] is marked RWE 
>>>>(on other archs it is RW). Is it necessary or is it a toolchain problem 
>>>>only?
>>>
>>>As I recall, that was done on mips[el] since we were having
>>>problems making gdb work.  I suspect that setting things RWE
>>>is no longer necessary.  Care to revert that and confirm that
>>>gdb still works?
>>
>>How/what to revert?
> 
> 
> It turns out that the mprotect call I was thinking of has already
> been reverted.  And because I wasn't reading carefully it turns
> out I didn't answer your question at all...  :-)
> 
> I have no idea why this happens.  I see nothing causing it in the
> kernel, or in uClibc/ldso/ldso/.  The mips ABI (SysV ABI, MIPS
> Supplement, 3rd Edition) only shows .dynamic as type SHF_ALLOC
> (section occupies memory during process execution), and doesn't
> show READ, WRITE, or EXEC...
> 

ld.so should set the DT_DEBUG entry in the dynamic segment to the proper
value (the link map for the object ??).

The problem is that the linker puts the dynamic segment in the read only
LOAD segment so that you get a SEGV in ld.so when it is not writable.  Thus
the need for the mprotect call.

Many things do not care about the value of the DT_DEBUG entry, but IIRC
things like boemh-gc and gdb do.

I gave up on making libgcj (which uses boehm-gc) work with uClibc for the
time being, but might want to do it in the future.  So it would be nice if
we could come up with some method of getting the DT_DEBUG entries set to
the proper value.


David Daney.




More information about the uClibc mailing list