[GOLD][PATCH] Added support for R_ARM_V4BX relocation (with interworking)
Tue Jan 19 01:27:00 GMT 2010
Sorry, I wanted to say -- "I'm not sure that it is a right behaviour ...". Sorry once again.
>I am still not sure why you want to put R_ARM_V4BX in a data section
>or if this is a right thing to do.
Technically, it is possible to put R_ARM_V4BX in a data section. I don't wanna say what it is a regular thing, but it is allowed to write something like that:
.section .my_data, "aw"
ldr r0, .LBX
bx r0 @ << R_ARM_V4BX
and AS will generate an object file with R_ARM_V4BX in the .my_data section and we should handle this relocation I suppose.
From: Doug Kwan ($Bop?6y~(B) [email@example.com]
Sent: Monday, January 18, 2010 5:01 PM
To: Viktor Kutuzov
Subject: Re: [GOLD][PATCH] Added support for R_ARM_V4BX relocation (with interworking)
2010/1/18 Viktor Kutuzov <firstname.lastname@example.org>:
> [VK] There is only one important (on my sight) reason to use only one glue owner stub table -- I'm not sure that it is not a right behavior to expand the non-executable segments with the veneer code if those segments have the V4BX relocations. What do you think?
If you think it is okay to put a R_ARM_V4BX in a non-executable
section, why is it a problem to put the stub table in such a section?
I am still not sure why you want to put R_ARM_V4BX in a data section
or if this is a right thing to do.
>> There is even no guarantee that the glue owner stub table and the section using it will be in memory at the same time if overlays is allowed
> yes, this might be a point against of my suggestion. ok.
More information about the Binutils