ARM mapping symbols
Bruno De Bus
bdebus@elis.ugent.be
Mon Mar 8 12:45:00 GMT 2004
On Mon, 8 Mar 2004, Nick Clifton wrote:
> Hi Bruno,
>
> [Please could send patches to the GNU binary utilities, including
> GAS, to the binutils mailing list: binutils@sources.redhat.com]
>
> > I noticed that you implemented mapping symbols for the
> > ARM-architecture. However, it seems like the literal pools (the
> > main reason for data in code on the ARM ) do not get a $d
> > symbol. The attached patch solves the problem.
>
> Thank you very much for submitting this patch. There is one initial
> problem however: do you have a copyright assignment on file with the
> FSF ? Without such an assignment we could not accept the patch :-(
Is this really necessary? The patch is very small (I add a parameter to
the mapping_state function, change all call sites (11 lines) and
change one check in mapping state to check the extra parameter (1 line)),
so I believe this would fall under "not legally significant for
copyright". If it is, please give me some more info on this
copyright assignment.
>
> > It's just a quick hack, I simply force the addition of a $d
> > symbol before each literal pool. For a clean fix, I would have
> > needed to change some of the core gas files.
>
> Which files ? [Clean fixes are always preferred to quick hacks :-)]
See the comments below...
>
> I have some reservations about the patch:
>
> * Why is the forced argument needed for the mapping_state() function
> ? Surely if the last mapping symbol emitted was a data symbol,
> then there is no need to emit a new one ?
That would be the case if the object was assembled from top to bottom,
which is not the case for the literal pools. As the literal pools
need to be appended after a function return or an unconditional jump they
cannot be assembled until the rest of the code is assembled. Although this
could probably be handled differently, at the moment the creation of the
table is even deferred until all sections are assembled.
(It is called in arm_cleanup:
void arm_cleanup()
{
literal_pool * pool;
for (pool = list_of_pools; pool; pool = pool->next)
{
/* Put it at the end of the relevent section. */
subseg_set (pool->section, pool->sub_section);
s_ltorg (0);
}
}
)
Correct me if I'm mistaking, but it appears to me that this is the only
place in the code where the tables can be emitted (which would mean that
all literal pools are at the end of a section). This would cause problems
if the code section became to big to address the literal pool (larger
than 4K for 32 bit loads, 256 bytes for halfword loads), but as far
as I can see, literal pools are only used in some assembly files, like
crt0.S that are small enough... (gcc does not use the literal pool
implementation in GAS, but inserts its own tables...)
So, what is the problem:
The last assembled section is often a data section, so the mapping symbol
is $d. Then arm_cleanup is called and the literal pool(s) is(/are)
written. As the last symbol already was $d, no new symbol is added...
the same would happen if you would add literal pools to different
sections: the first could get a $d symbol, the others would not...
> Which files ? [Clean fixes are always preferred to quick hacks :-)]
It would also be possible to change subseg_set to find out when we jump
from one part of the file to another. This would probably be cleaner....
> * If you are going to emit a data symbol at the start of the literal
> pool, then you will also need to emit a text symbol at the end of
> the pool, so that debuggers etc can tell that .text section now
> contains code and not data.
Yep, if there were literal pools that were not at the end of a section.
> Cheers
> Nick
>
>
-------------- next part --------------
diff -uNr binutils-2.14.90.0.8/gas/config/tc-arm.c binutils-2.14.90.0.8-patched/gas/config/tc-arm.c
--- binutils-2.14.90.0.8/gas/config/tc-arm.c 2004-01-14 22:07:45.000000000 +0100
+++ binutils-2.14.90.0.8-patched/gas/config/tc-arm.c 2004-02-24 17:19:01.000000000 +0100
@@ -2903,14 +2903,14 @@
implemented here. */
static void
-mapping_state (enum mstate state)
+mapping_state (enum mstate state, bfd_boolean forced)
{
static enum mstate mapstate = MAP_DATA;
symbolS * symbolP;
const char * symname;
int type;
- if (mapstate == state)
+ if ((mapstate == state) && (!forced))
/* The mapping symbol has already been emitted.
There is nothing else to do. */
return;
@@ -2978,16 +2978,16 @@
if (flags & SEC_CODE)
{
if (thumb_mode)
- mapping_state (MAP_THUMB);
+ mapping_state (MAP_THUMB,FALSE);
else
- mapping_state (MAP_ARM);
+ mapping_state (MAP_ARM,FALSE);
}
else
/* This section does not contain code. Therefore it must contain data. */
- mapping_state (MAP_DATA);
+ mapping_state (MAP_DATA,FALSE);
}
#else
-#define mapping_state(a)
+#define mapping_state(a,b)
#endif /* OBJ_ELF */
@@ -3077,7 +3077,7 @@
marking in_bss, then looking at s_skip for clues. */
subseg_set (bss_section, 0);
demand_empty_rest_of_line ();
- mapping_state (MAP_DATA);
+ mapping_state (MAP_DATA,FALSE);
}
static void
@@ -3121,6 +3121,8 @@
symbol_table_insert (pool->symbol);
ARM_SET_THUMB (pool->symbol, thumb_mode);
+
+ mapping_state (MAP_DATA,TRUE);
#if defined OBJ_COFF || defined OBJ_ELF
ARM_SET_INTERWORK (pool->symbol, support_interwork);
@@ -3316,7 +3318,7 @@
coming from ARM mode, which is word-aligned. */
record_alignment (now_seg, 1);
}
- mapping_state (MAP_THUMB);
+ mapping_state (MAP_THUMB,FALSE);
break;
case 32:
@@ -3332,7 +3334,7 @@
record_alignment (now_seg, 1);
}
- mapping_state (MAP_ARM);
+ mapping_state (MAP_ARM,FALSE);
break;
default:
@@ -12984,7 +12986,7 @@
return;
}
- mapping_state (MAP_THUMB);
+ mapping_state (MAP_THUMB,FALSE);
inst.instruction = opcode->value;
inst.size = opcode->size;
(*opcode->parms) (p);
@@ -13010,7 +13012,7 @@
return;
}
- mapping_state (MAP_ARM);
+ mapping_state (MAP_ARM,FALSE);
inst.instruction = opcode->value;
inst.size = INSN_SIZE;
(*opcode->parms) (p);
@@ -14153,7 +14155,7 @@
md_cons_align (nbytes);
#endif
- mapping_state (MAP_DATA);
+ mapping_state (MAP_DATA,FALSE);
do
{
bfd_reloc_code_real_type reloc;
More information about the Binutils
mailing list