can anybody explain about current situation with BREL Relocations ?

I've played around some more with linking with and without -N, and what effect that has on the resulting executable.

elf.library allocates tracked memory when loading a program, so the TrackedAddr tab in Ranger conveniently shows all the loaded sections and the addresses they live at (the sizes of all the tracked memory allocations exactly match the section sizes that readelf reports).

Ranger doesn't report the memory attributes of those allocations, so I wrote a quick'n'dirty tool to call IMMU->GetMemoryAttrs() for any address I give it. With this I was able to confirm that the only difference between code linked with -N and code linked without it is that the .text section is writeable with -N, and is read-only with the standard ldscript. .rodata and .__newlib_version are read-only for both both ldscript versions, and all the other sections are writeable for both versions.

Curiously, the .text sections are not marked as executable, at least not as reported by IMMU->GetMemoryAttrs(). The address of the loaded .text sections is notably different than all the other sections, so perhaps some other mechanism is used to set aside a block of memory as executable. (Maybe the segment registers joerg mentioned? This is an X1000...)

Leaving the code writeable is more of a risk, especially for a program like PassPocket that is trying to prevent malicious code from potentially messing with it. So I guess it's time to change my linking habits.

@All
We a bit on the line to be in the beta state for some fresh release of new binutils, but for that we need to pass some more tests about which we had issues before, and one of the latest issues we want to sort out is that "baserel" stuff.

But testing this is not trivial (for us at least), as we don't know how to write proper test case to test baserel stuff.

All we find, is that in adtools, there are some old/unmaintained test cases written years ago to be tested on qemu: there they are:

https://github.com/sba1/adtools/blob/m ... ests/test-baserel-large.c
https://github.com/sba1/adtools/blob/master/tests/test-baserel.c

and they share some "common.h" file in the same place.

So far, they should be compiled like this:



Problem is that common.h had:



causing:



It can be very well that back in days -me500 were enough to say to AS to handle proper opcode, but today surely not, and for sake of tests i provide something -mcpu=e5500 instead to make it compiles. But then binary simple crashes.

All of this sounds kind of hardcore, so, maybe anyone can wrote a simple-little test case for both baserel and baserel-large parts (the ones we need to support probably), without all those specific to CPU opcodes, so we can test it ?

Thanks !

@kas1e

Funny how the different PowerPC are different.

https://elinux.org/Book_E_and_PPC_440

It has do with MMU, so perhaps something can be rewritten use the ExecSG mmu api instead.

@LiveForIT
Quote:

Is for simple testing, baserel stuff needs to use any registers/mmu/whatever at all ? I mean, isn't it possible to write some very simple and basic test case testing baserel features ?

@kas1e

Tricky when need to know the small difference between PowerPC chips are to write assembly,
do you need to write it in assembly, and does it do what you actually want it to do?
(if its just a test, perhaps it can be tested on Sam440. If not required to test on others.) Perhaps the sam460 is similar.
since they both are AMCC chips

@LiveForIT
As i say in previous post, we don't need any assembler, or anything hardcore. All we need is ANY simple test case which will test if baserel mode work in compiler or not.

Any simple test case, with less as possible code, and with no assembler preferable.

Also, to repeat myself again: we don't need to test CPU, specific arch or whatever. We need to test if baserel mode works in binutils/gcc we works on : for that we need simple test case which is NOT cpu specific, not arch based, nothing at all. Just simple test case which we can run, and it will printf "ok baserel works", "ops, baserel not works". Then we can test it with old gcc/bintuils, current gcc/bintuils and new gcc/bintuils we works on. That why we need it.

The test code i point out from adtools are old and not-working, i only point out on them as on only ones which were possible to find at all. But we need of course different, better and easy test case.

@kas1e

There's no such thing as as simple test case for this, but I can come up with something when I have time. A proper test case will need to make use of IElf->CopyDataSegment() to fully cover all eventualities.

As mentioned earlier, maybe once baserel is working again, perhaps that code could be adapted to make it possible to define functions where r13 can automatically be saved/restored (like __saveds) for when using -msdata instead of -mbaserel.

@Futaura

That would be very nice, if you could put together an example. What ever times it takes you. I'm in no hurry.