* [ARM] global Thumb to ARM branches broken @ 2010-02-03 15:16 Christophe LYON 2010-02-03 16:16 ` Ramana Radhakrishnan 0 siblings, 1 reply; 10+ messages in thread From: Christophe LYON @ 2010-02-03 15:16 UTC (permalink / raw) To: Binutils Hello, It seems to me that the patch discussed in http://sourceware.org/ml/binutils/2009-03/msg00511.html broke the global Thumb branches by encoding the PC inside the instruction. For instance: .global _start .syntax unified .text .thumb_func _start: .global bar .space 0x300000 bl bar .section .foo, "xa" .arm .type bar, %function bar: bx lr is assembled into (using -march=armv5t): 00000000 <_start>: ... 300000: f4ff fffe bl ffd00000 <_start+0xffd00000> 300000: R_ARM_THM_CALL bar Disassembly of section .foo: 00000000 <bar>: 0: e12fff1e bx lr In turn, if one links, the resulting code is: 00008000 <_start>: ... 308000: f500 e800 blx 8004 <_start+0x4> Disassembly of section .foo: 00308004 <bar>: 308004: e12fff1e bx lr This is because Ramana's fix in md_pcrel_from_section() does not check whether both sides of the branch are in the same section, or if the destination is external. I am working on a patch, but some inputs/comments could help. Indeed, I am not sure what "in line with what happens with global functions for both ARM and Thumb mode" really means (as appears in the original post). As I am not sure about the actual intent of that patch, I tried to remove some parts, which did not result in regressions in the testsuite, so some tests may be missing. Finally, I am not sure about the new behaviour of arm_force_relocation(): it now returns 1 in several new occurrences, but the corresponding relocations do not appear in the object file (see blx-local test) I am trying to fix gas, but maybe a better fix would be in the linker side, because the involved relocations are declared as *not* partial inplace, but ld handles them as if they were (eg when it reads the addend from upper_insn). Christophe. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ARM] global Thumb to ARM branches broken 2010-02-03 15:16 [ARM] global Thumb to ARM branches broken Christophe LYON @ 2010-02-03 16:16 ` Ramana Radhakrishnan 2010-02-04 16:46 ` Christophe LYON 0 siblings, 1 reply; 10+ messages in thread From: Ramana Radhakrishnan @ 2010-02-03 16:16 UTC (permalink / raw) To: Christophe LYON; +Cc: Binutils I'll need to take a slightly more detailed look later and get back to you but here's something about the intent of the patch. On Wed, 2010-02-03 at 16:15 +0100, Christophe LYON wrote: > Hello, > > It seems to me that the patch discussed in > http://sourceware.org/ml/binutils/2009-03/msg00511.html > broke the global Thumb branches by encoding the PC inside the instruction. > > For instance: > .global _start > .syntax unified > .text > .thumb_func > _start: > .global bar > .space 0x300000 > bl bar > > .section .foo, "xa" > .arm > .type bar, %function > bar: > bx lr > > is assembled into (using -march=armv5t): > 00000000 <_start>: > ... > 300000: f4ff fffe bl ffd00000 <_start+0xffd00000> > 300000: R_ARM_THM_CALL bar > Disassembly of section .foo: > 00000000 <bar>: > 0: e12fff1e bx lr > > In turn, if one links, the resulting code is: > 00008000 <_start>: > ... > 308000: f500 e800 blx 8004 <_start+0x4> > Disassembly of section .foo: > 00308004 <bar>: > 308004: e12fff1e bx lr At the time I did this, I don't think I considered cases across sections and that doesn't seem to be right. So it looks like this is a bit broken. > > This is because Ramana's fix in md_pcrel_from_section() does not check > whether both sides of the branch are in the same section, or if the > destination is external. > > I am working on a patch, but some inputs/comments could help. > Indeed, I am not sure what "in line with what happens with global > functions for both ARM and Thumb mode" really means (as appears in the > original post). > > As I am not sure about the actual intent of that patch, I tried to > remove some parts, which did not result in regressions in the testsuite, > so some tests may be missing. The original intent of the patch [1] was to transform any form of branches and / or calls to local functions in the assembler from ARM state to Thumb state and vice versa automatically. Also pushing out the appropriate relocations for the linker to veneer for conditional branches (and architectural variants) was the intent of this patch. The reason for having this logic in the assembler is for the case where you have function calls / branches to transform from one state to the other and push the rest out to the linker to handle by veneering. For arch versions that didn't have the equivalent {x} variant we would want to push out the relocations. > Finally, I am not sure about the new behaviour of > arm_force_relocation(): it now returns 1 in several new occurrences, but > the corresponding relocations do not appear in the object file (see > blx-local test) I'll have to take another look at this and get back to you. > > I am trying to fix gas, but maybe a better fix would be in the linker > side, because the involved relocations are declared as *not* partial > inplace, but ld handles them as if they were (eg when it reads the > addend from upper_insn). I would still try and fix this in GAS by converting bl's to blx's at the right times. and pushing out relocs where GAS can't handle it for the linker to handle. cheers Ramana [1] This was a part of a project that I was doing to get GCC to automatically generate ARM and Thumb state functions within the same compilation unit. That is still on the horizon, but having the support in the assembler was necessary to allow cases where you had function calls to static functions working correctly. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ARM] global Thumb to ARM branches broken 2010-02-03 16:16 ` Ramana Radhakrishnan @ 2010-02-04 16:46 ` Christophe LYON 2010-02-05 10:08 ` Ramana Radhakrishnan 0 siblings, 1 reply; 10+ messages in thread From: Christophe LYON @ 2010-02-04 16:46 UTC (permalink / raw) To: ramana.radhakrishnan; +Cc: Binutils > The reason for having this logic in the assembler is for the case where > you have function calls / branches to transform from one state to the > other and push the rest out to the linker to handle by veneering. For > arch versions that didn't have the equivalent {x} variant we would want > to push out the relocations. I don't understand why your patch to md_pcrel_from_section does not involve S_IS_EXTERNAL, while your patch to md_apply_fix does. Could you explain it to me? >> Finally, I am not sure about the new behaviour of >> arm_force_relocation(): it now returns 1 in several new occurrences, but >> the corresponding relocations do not appear in the object file (see >> blx-local test) > > I'll have to take another look at this and get back to you. > Actually, it seems that I misunderstood the purpose of arm_force_relocation. It just triggers a flag for gas internal use, which is set appropriately in md_apply_fix. Christophe. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ARM] global Thumb to ARM branches broken 2010-02-04 16:46 ` Christophe LYON @ 2010-02-05 10:08 ` Ramana Radhakrishnan 2010-02-05 13:44 ` Christophe LYON 0 siblings, 1 reply; 10+ messages in thread From: Ramana Radhakrishnan @ 2010-02-05 10:08 UTC (permalink / raw) To: Christophe LYON; +Cc: Binutils [-- Attachment #1: Type: text/plain, Size: 1616 bytes --] I had a quick look at this - On Thu, 2010-02-04 at 17:46 +0100, Christophe LYON wrote: > > The reason for having this logic in the assembler is for the case where > > you have function calls / branches to transform from one state to the > > other and push the rest out to the linker to handle by veneering. For > > arch versions that didn't have the equivalent {x} variant we would want > > to push out the relocations. > > I don't understand why your patch to md_pcrel_from_section does not > involve S_IS_EXTERNAL, while your patch to md_apply_fix does. Could you > explain it to me? IIRC because md_pcrel_from_section is never called for an external unresolved reference or even if it is the base value should always be 0 ? > > >> Finally, I am not sure about the new behaviour of > >> arm_force_relocation(): it now returns 1 in several new occurrences, but > >> the corresponding relocations do not appear in the object file (see > >> blx-local test) > > > > I'll have to take another look at this and get back to you. > > > Actually, it seems that I misunderstood the purpose of > arm_force_relocation. It just triggers a flag for gas internal use, > which is set appropriately in md_apply_fix. I think the solution would be that base in md_pcrel_from_section should not be reset when the 2 segments aren't the same i.e. each of the relocs should make sure that `base' is reset only for internal . I tried this patch and things worked with no regressions and it appeared to also fix your case. I don't have more time to work on this in the next week or so, but hope this helps. cheers Ramana [-- Attachment #2: fix.patch --] [-- Type: text/x-patch, Size: 2194 bytes --] Index: tc-arm.c =================================================================== RCS file: /cvs/src/src/gas/config/tc-arm.c,v retrieving revision 1.428 diff -a -u -r1.428 tc-arm.c --- tc-arm.c 29 Jan 2010 16:02:39 -0000 1.428 +++ tc-arm.c 4 Feb 2010 18:40:17 -0000 @@ -19241,17 +19241,19 @@ case BFD_RELOC_THUMB_PCREL_BRANCH23: if (fixP->fx_addsy - && ARM_IS_FUNC (fixP->fx_addsy) - && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) - base = fixP->fx_where + fixP->fx_frag->fr_address; + && ARM_IS_FUNC (fixP->fx_addsy) + && (fixP->fx_addsy && S_GET_SEGMENT (fixP->fx_addsy) == seg) + && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) + base = fixP->fx_where + fixP->fx_frag->fr_address; return base + 4; /* BLX is like branches above, but forces the low two bits of PC to zero. */ case BFD_RELOC_THUMB_PCREL_BLX: if (fixP->fx_addsy - && THUMB_IS_FUNC (fixP->fx_addsy) - && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) + && THUMB_IS_FUNC (fixP->fx_addsy) + && (fixP->fx_addsy && S_GET_SEGMENT (fixP->fx_addsy) == seg) + && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) base = fixP->fx_where + fixP->fx_frag->fr_address; return (base + 4) & ~3; @@ -19259,18 +19261,19 @@ loader expects the relocation not to take this into account. */ case BFD_RELOC_ARM_PCREL_BLX: if (fixP->fx_addsy - && ARM_IS_FUNC (fixP->fx_addsy) - && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) + && ARM_IS_FUNC (fixP->fx_addsy) + && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) base = fixP->fx_where + fixP->fx_frag->fr_address; return base + 8; case BFD_RELOC_ARM_PCREL_CALL: if (fixP->fx_addsy - && THUMB_IS_FUNC (fixP->fx_addsy) - && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) + && (fixP->fx_addsy && S_GET_SEGMENT (fixP->fx_addsy) == seg) + && THUMB_IS_FUNC (fixP->fx_addsy) + && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) base = fixP->fx_where + fixP->fx_frag->fr_address; return base + 8; - + case BFD_RELOC_ARM_PCREL_BRANCH: case BFD_RELOC_ARM_PCREL_JUMP: case BFD_RELOC_ARM_PLT32: ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ARM] global Thumb to ARM branches broken 2010-02-05 10:08 ` Ramana Radhakrishnan @ 2010-02-05 13:44 ` Christophe LYON 2010-02-08 16:09 ` Christophe LYON 0 siblings, 1 reply; 10+ messages in thread From: Christophe LYON @ 2010-02-05 13:44 UTC (permalink / raw) To: ramana.radhakrishnan; +Cc: Binutils >> I don't understand why your patch to md_pcrel_from_section does not >> involve S_IS_EXTERNAL, while your patch to md_apply_fix does. Could you >> explain it to me? > > IIRC because md_pcrel_from_section is never called for an external > unresolved reference or even if it is the base value should always be > 0 ? S_IS_EXTERNAL does not mean "external unresolved reference", and I am just adding test cases to cover these cases as well, which takes time. And as I am out of luck, now I have found a bug in objdump :-( > > I think the solution would be that base in md_pcrel_from_section should > not be reset when the 2 segments aren't the same i.e. each of the relocs > should make sure that `base' is reset only for internal . I tried this > patch and things worked with no regressions and it appeared to also fix > your case. > Yes, my current patch is very similar, but adding tests to cover every line of new code takes time (especially as it triggers oddities or bugs elsewhere :-) Christophe. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ARM] global Thumb to ARM branches broken 2010-02-05 13:44 ` Christophe LYON @ 2010-02-08 16:09 ` Christophe LYON 2010-02-09 10:17 ` Nick Clifton 0 siblings, 1 reply; 10+ messages in thread From: Christophe LYON @ 2010-02-08 16:09 UTC (permalink / raw) To: ramana.radhakrishnan; +Cc: Binutils [-- Attachment #1: Type: text/plain, Size: 118 bytes --] Hi, Here is the patch I promised last week, along with the related test cases. Can I commit it? Thanks Christophe. [-- Attachment #2: global-branches.changelog --] [-- Type: text/plain, Size: 474 bytes --] 2010-02-08 Christophe Lyon <christophe.lyon@st.com> gas/ * config/tc-arm.c (md_pcrel_from_section): Keep base to zero for non-local branches (BFD_RELOC_THUMB_PCREL_BRANCH23, BFD_RELOC_THUMB_PCREL_BLX, BFD_RELOC_ARM_PCREL_BLX, BFD_RELOC_ARM_PCREL_CALL) gas/testsuite/ * gas/arm/branch-reloc.s, gas/arm/branch-reloc.d, gas/arm/branch-reloc.l: New tests and expected results with all variants of call: ARM/Thumb, local/global, inter/intra-section, using BL/BLX. [-- Attachment #3: global-branches.patch --] [-- Type: text/x-patch, Size: 7262 bytes --] Index: gas/config/tc-arm.c =================================================================== RCS file: /cvs/src/src/gas/config/tc-arm.c,v retrieving revision 1.428 diff -u -b -p -r1.428 tc-arm.c --- gas/config/tc-arm.c 29 Jan 2010 16:02:39 -0000 1.428 +++ gas/config/tc-arm.c 8 Feb 2010 16:00:32 -0000 @@ -19241,6 +19241,8 @@ md_pcrel_from_section (fixS * fixP, segT case BFD_RELOC_THUMB_PCREL_BRANCH23: if (fixP->fx_addsy + && (S_GET_SEGMENT (fixP->fx_addsy) == seg) + && (!S_IS_EXTERNAL (fixP->fx_addsy)) && ARM_IS_FUNC (fixP->fx_addsy) && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) base = fixP->fx_where + fixP->fx_frag->fr_address; @@ -19250,6 +19252,8 @@ md_pcrel_from_section (fixS * fixP, segT zero. */ case BFD_RELOC_THUMB_PCREL_BLX: if (fixP->fx_addsy + && (S_GET_SEGMENT (fixP->fx_addsy) == seg) + && (!S_IS_EXTERNAL (fixP->fx_addsy)) && THUMB_IS_FUNC (fixP->fx_addsy) && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) base = fixP->fx_where + fixP->fx_frag->fr_address; @@ -19259,6 +19263,8 @@ md_pcrel_from_section (fixS * fixP, segT loader expects the relocation not to take this into account. */ case BFD_RELOC_ARM_PCREL_BLX: if (fixP->fx_addsy + && (S_GET_SEGMENT (fixP->fx_addsy) == seg) + && (!S_IS_EXTERNAL (fixP->fx_addsy)) && ARM_IS_FUNC (fixP->fx_addsy) && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) base = fixP->fx_where + fixP->fx_frag->fr_address; @@ -19266,6 +19272,8 @@ md_pcrel_from_section (fixS * fixP, segT case BFD_RELOC_ARM_PCREL_CALL: if (fixP->fx_addsy + && (S_GET_SEGMENT (fixP->fx_addsy) == seg) + && (!S_IS_EXTERNAL (fixP->fx_addsy)) && THUMB_IS_FUNC (fixP->fx_addsy) && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t)) base = fixP->fx_where + fixP->fx_frag->fr_address; Index: gas/testsuite/gas/arm/branch-reloc.d =================================================================== RCS file: gas/testsuite/gas/arm/branch-reloc.d diff -N gas/testsuite/gas/arm/branch-reloc.d --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gas/testsuite/gas/arm/branch-reloc.d 8 Feb 2010 16:00:33 -0000 @@ -0,0 +1,89 @@ +#name: Inter-section branch relocations +#This test is only valid on ELF based ports. +#not-target: *-*-*coff *-*-pe *-*-wince *-*-*aout* *-*-netbsd *-*-riscix* +#as: -march=armv5t +#objdump: -rd +#stderr: branch-reloc.l + +# Test the generation of relocation for inter-section branches + +.*: +file format.*arm.* + + +Disassembly of section .text: + +00000000 <arm_glob_sym1-0x4>: + 0: e1a00000 nop ; \(mov r0, r0\) + +00000004 <arm_glob_sym1>: + 4: ebfffffe bl 46 <thumb_glob_sym1> + 4: R_ARM_CALL thumb_glob_sym1 + 8: ebfffffe bl 100 <thumb_glob_sym2> + 8: R_ARM_CALL thumb_glob_sym2 + c: fa00000c blx 44 <thumb_sym1> + 10: ebfffffe bl 4 <arm_glob_sym1> + 10: R_ARM_CALL arm_glob_sym1 + 14: ebfffffe bl 13c <arm_glob_sym2> + 14: R_ARM_CALL arm_glob_sym2 + 18: eb000007 bl 3c <arm_sym1> + 1c: fafffffe blx 46 <thumb_glob_sym1> + 1c: R_ARM_CALL thumb_glob_sym1 + 20: fafffffe blx 100 <thumb_glob_sym2> + 20: R_ARM_CALL thumb_glob_sym2 + 24: fa000006 blx 44 <thumb_sym1> + 28: fafffffe blx 4 <arm_glob_sym1> + 28: R_ARM_CALL arm_glob_sym1 + 2c: fafffffe blx 13c <arm_glob_sym2> + 2c: R_ARM_CALL arm_glob_sym2 + 30: eb000001 bl 3c <arm_sym1> + 34: e1a00000 nop ; \(mov r0, r0\) + 38: e12fff1e bx lr + +0000003c <arm_sym1>: + 3c: e1a00000 nop ; \(mov r0, r0\) + 40: e12fff1e bx lr + +00000044 <thumb_sym1>: + 44: 4770 bx lr + +00000046 <thumb_glob_sym1>: + 46: 4770 bx lr + +Disassembly of section foo: + +00000000 <thumb_glob_sym2-0x100>: + ... + +00000100 <thumb_glob_sym2>: + 100: f7ff fffe bl 4 <thumb_glob_sym2-0xfc> + 100: R_ARM_THM_CALL arm_glob_sym1 + 104: f7ff fffe bl 13c <arm_glob_sym2> + 104: R_ARM_THM_CALL arm_glob_sym2 + 108: f000 e816 blx 138 <arm_sym2> + 10c: f7ff fffe bl 46 <thumb_glob_sym2-0xba> + 10c: R_ARM_THM_CALL thumb_glob_sym1 + 110: f7ff fffe bl 100 <thumb_glob_sym2> + 110: R_ARM_THM_CALL thumb_glob_sym2 + 114: f000 f80e bl 134 <thumb_sym2> + 118: f7ff effe blx 4 <thumb_glob_sym2-0xfc> + 118: R_ARM_THM_CALL arm_glob_sym1 + 11c: f7ff effe blx 13c <arm_glob_sym2> + 11c: R_ARM_THM_CALL arm_glob_sym2 + 120: f000 e80a blx 138 <arm_sym2> + 124: f7ff effe blx 46 <thumb_glob_sym2-0xba> + 124: R_ARM_THM_CALL thumb_glob_sym1 + 128: f7ff effe blx 100 <thumb_glob_sym2> + 128: R_ARM_THM_CALL thumb_glob_sym2 + 12c: f000 f802 bl 134 <thumb_sym2> + 130: 46c0 nop ; \(mov r8, r8\) + 132: 4770 bx lr + +00000134 <thumb_sym2>: + 134: 46c0 nop ; \(mov r8, r8\) + 136: 4770 bx lr + +00000138 <arm_sym2>: + 138: e12fff1e bx lr + +0000013c <arm_glob_sym2>: + 13c: e12fff1e bx lr Index: gas/testsuite/gas/arm/branch-reloc.l =================================================================== RCS file: gas/testsuite/gas/arm/branch-reloc.l diff -N gas/testsuite/gas/arm/branch-reloc.l --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gas/testsuite/gas/arm/branch-reloc.l 8 Feb 2010 16:00:33 -0000 @@ -0,0 +1,3 @@ +[^:]*: Assembler messages: +[^:]*:[0-9]*: Warning: blx to 'arm_sym1' an ARM ISA state function changed to bl +[^:]*:[0-9]*: Warning: blx to Thumb func 'thumb_sym2' from Thumb ISA state changed to bl \ No newline at end of file Index: gas/testsuite/gas/arm/branch-reloc.s =================================================================== RCS file: gas/testsuite/gas/arm/branch-reloc.s diff -N gas/testsuite/gas/arm/branch-reloc.s --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gas/testsuite/gas/arm/branch-reloc.s 8 Feb 2010 16:00:33 -0000 @@ -0,0 +1,87 @@ +@ Check that non-local branches with and without mode switching +@ produce the right relocations with appropriate in-place addends. + + .syntax unified + + .text + .arm + .global arm_glob_sym1 + .global arm_glob_sym2 + .global thumb_glob_sym1 + .global thumb_glob_sym2 + nop + .type arm_glob_sym1, %function +arm_glob_sym1: + bl thumb_glob_sym1 + bl thumb_glob_sym2 + bl thumb_sym1 + bl arm_glob_sym1 + bl arm_glob_sym2 + bl arm_sym1 + blx thumb_glob_sym1 + blx thumb_glob_sym2 + blx thumb_sym1 + blx arm_glob_sym1 + blx arm_glob_sym2 + blx arm_sym1 + nop + bx lr + + .type arm_sym1, %function +arm_sym1: + nop + bx lr + + .thumb + .thumb_func + .type thumb_sym1, %function +thumb_sym1: + bx lr + + .type thumb_glob_sym1, %function + .thumb_func + .thumb +thumb_glob_sym1: + bx lr + + .section foo,"ax" + +@ Add some space to avoid confusing objdump output: as we are +@ producing a relocatable file, objdump may match an address to +@ the wrong symbol (as symbols in different sections may have the same +@ address in the object file). + .space 0x100 + + .type thumb_glob_sym2, %function + .thumb_func + .thumb +thumb_glob_sym2: + bl arm_glob_sym1 + bl arm_glob_sym2 + bl arm_sym2 + bl thumb_glob_sym1 + bl thumb_glob_sym2 + bl thumb_sym2 + blx arm_glob_sym1 + blx arm_glob_sym2 + blx arm_sym2 + blx thumb_glob_sym1 + blx thumb_glob_sym2 + blx thumb_sym2 + nop + bx lr + + .type thumb_sym2, %function +thumb_sym2: + nop + bx lr + + .arm + .type arm_sym2, %function +arm_sym2: + bx lr + + .global arm_glob_sym2 + .type arm_glob_sym2, %function +arm_glob_sym2: + bx lr ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ARM] global Thumb to ARM branches broken 2010-02-08 16:09 ` Christophe LYON @ 2010-02-09 10:17 ` Nick Clifton 2010-02-09 14:45 ` Christophe LYON 0 siblings, 1 reply; 10+ messages in thread From: Nick Clifton @ 2010-02-09 10:17 UTC (permalink / raw) To: Christophe LYON; +Cc: ramana.radhakrishnan, Binutils Hi Christophe, > Here is the patch I promised last week, along with the related test cases. > Can I commit it? Yes - please do. Cheers Nick ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ARM] global Thumb to ARM branches broken 2010-02-09 10:17 ` Nick Clifton @ 2010-02-09 14:45 ` Christophe LYON 2010-02-11 12:42 ` Tristan Gingold 0 siblings, 1 reply; 10+ messages in thread From: Christophe LYON @ 2010-02-09 14:45 UTC (permalink / raw) To: Nick Clifton; +Cc: ramana.radhakrishnan, Binutils On 09.02.2010 11:16, Nick Clifton wrote: > Yes - please do. > Thanks, done. Christophe. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ARM] global Thumb to ARM branches broken 2010-02-09 14:45 ` Christophe LYON @ 2010-02-11 12:42 ` Tristan Gingold 2010-02-11 14:33 ` Christophe LYON 0 siblings, 1 reply; 10+ messages in thread From: Tristan Gingold @ 2010-02-11 12:42 UTC (permalink / raw) To: Christophe LYON Cc: ramana.radhakrishnan@arm.com >> Ramana Radhakrishnan, Binutils On Feb 9, 2010, at 3:45 PM, Christophe LYON wrote: > On 09.02.2010 11:16, Nick Clifton wrote: > >> Yes - please do. >> > > Thanks, done. > Christophe. Christophe, which patches should be put on the 2.20 branch ? (It would be much easier for me if you commit the right one on the branch :-) Tristan. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [ARM] global Thumb to ARM branches broken 2010-02-11 12:42 ` Tristan Gingold @ 2010-02-11 14:33 ` Christophe LYON 0 siblings, 0 replies; 10+ messages in thread From: Christophe LYON @ 2010-02-11 14:33 UTC (permalink / raw) To: Tristan Gingold Cc: ramana.radhakrishnan@arm.com >> Ramana Radhakrishnan, Binutils > which patches should be put on the 2.20 branch ? This patch requires my other patch on objdump. > (It would be much easier for me if you commit the right one on the branch :-) I'll do it. Christophe. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-02-11 14:33 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-02-03 15:16 [ARM] global Thumb to ARM branches broken Christophe LYON 2010-02-03 16:16 ` Ramana Radhakrishnan 2010-02-04 16:46 ` Christophe LYON 2010-02-05 10:08 ` Ramana Radhakrishnan 2010-02-05 13:44 ` Christophe LYON 2010-02-08 16:09 ` Christophe LYON 2010-02-09 10:17 ` Nick Clifton 2010-02-09 14:45 ` Christophe LYON 2010-02-11 12:42 ` Tristan Gingold 2010-02-11 14:33 ` Christophe LYON
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).