search for: ref_addr_relocation

...on, or should we put a label at >> the start of each CU? >> > > Either way should work. But since we already have the section offset for > each CU, describing relative to the start of debug_info section saves us a > few symbols :) > > >> >> 0002: >> ref_addr_relocation.ll: >> seems a bit vague in terms of how you test for the relocation. I >> think it'd make more sense to test the assembly, than the reafobj output, >> that way you can test that the correct bytes have the relocation rather >> than just that there's "some&qu...

...>>> >>> Either way should work. But since we already have the section offset for >>> each CU, describing relative to the start of debug_info section saves us a >>> few symbols :) >>> >>> >>>> >>>> 0002: >>>> ref_addr_relocation.ll: >>>> seems a bit vague in terms of how you test for the relocation. I >>>> think it'd make more sense to test the assembly, than the reafobj output, >>>> that way you can test that the correct bytes have the relocation rather >>>> than jus...

...>>> >>> Either way should work. But since we already have the section offset for >>> each CU, describing relative to the start of debug_info section saves us a >>> few symbols :) >>> >>> >>>> >>>> 0002: >>>> ref_addr_relocation.ll: >>>> seems a bit vague in terms of how you test for the relocation. I >>>> think it'd make more sense to test the assembly, than the reafobj output, >>>> that way you can test that the correct bytes have the relocation rather >>>> than jus...

...the start of each CU? >>> >> >> Either way should work. But since we already have the section offset for >> each CU, describing relative to the start of debug_info section saves us a >> few symbols :) >> >> >>> >>> 0002: >>> ref_addr_relocation.ll: >>> seems a bit vague in terms of how you test for the relocation. I >>> think it'd make more sense to test the assembly, than the reafobj output, >>> that way you can test that the correct bytes have the relocation rather >>> than just that there'...

...nce we already have the section offset >>>>> for each CU, describing relative to the start of debug_info section saves >>>>> us a few symbols :) >>>>> >>>>> >>>>>> >>>>>> 0002: >>>>>> ref_addr_relocation.ll: >>>>>> seems a bit vague in terms of how you test for the relocation. I >>>>>> think it'd make more sense to test the assembly, than the reafobj output, >>>>>> that way you can test that the correct bytes have the relocation rather &...

...ther way should work. But since we already have the section offset >>>> for each CU, describing relative to the start of debug_info section saves >>>> us a few symbols :) >>>> >>>> >>>>> >>>>> 0002: >>>>> ref_addr_relocation.ll: >>>>> seems a bit vague in terms of how you test for the relocation. I >>>>> think it'd make more sense to test the assembly, than the reafobj output, >>>>> that way you can test that the correct bytes have the relocation rather >>>&...

...the start of each CU? >>> >> >> Either way should work. But since we already have the section offset for >> each CU, describing relative to the start of debug_info section saves us a >> few symbols :) >> >> >>> >>> 0002: >>> ref_addr_relocation.ll: >>> seems a bit vague in terms of how you test for the relocation. I >>> think it'd make more sense to test the assembly, than the reafobj output, >>> that way you can test that the correct bytes have the relocation rather >>> than just that there'...

...ion offset >>>>>> for each CU, describing relative to the start of debug_info section saves >>>>>> us a few symbols :) >>>>>> >>>>>> >>>>>>> >>>>>>> 0002: >>>>>>> ref_addr_relocation.ll: >>>>>>> seems a bit vague in terms of how you test for the relocation. I >>>>>>> think it'd make more sense to test the assembly, than the reafobj output, >>>>>>> that way you can test that the correct bytes have the relocat...

...gt;> for each CU, describing relative to the start of debug_info section saves us >>>>>>> a few symbols :) >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 0002: >>>>>>>> ref_addr_relocation.ll: >>>>>>>> seems a bit vague in terms of how you test for the relocation. I >>>>>>>> think it'd make more sense to test the assembly, than the reafobj output, >>>>>>>> that way you can test that the correct bytes have...

...ion offset >>>>>> for each CU, describing relative to the start of debug_info section saves >>>>>> us a few symbols :) >>>>>> >>>>>> >>>>>>> >>>>>>> 0002: >>>>>>> ref_addr_relocation.ll: >>>>>>> seems a bit vague in terms of how you test for the relocation. I >>>>>>> think it'd make more sense to test the assembly, than the reafobj output, >>>>>>> that way you can test that the correct bytes have the relocat...

...gt;>> for each CU, describing relative to the start of debug_info section saves >>>>>>> us a few symbols :) >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 0002: >>>>>>>> ref_addr_relocation.ll: >>>>>>>> seems a bit vague in terms of how you test for the relocation. >>>>>>>> I think it'd make more sense to test the assembly, than the reafobj output, >>>>>>>> that way you can test that the correct bytes have...

...more test coverage while fixing this issue. Eric/Manman: rough design question: compute the absolute offset of each CU within the debug_info section and describe them all relative to a single symbol at the start of the debug_info section, or should we put a label at the start of each CU? 0002: ref_addr_relocation.ll: seems a bit vague in terms of how you test for the relocation. I think it'd make more sense to test the assembly, than the reafobj output, that way you can test that the correct bytes have the relocation rather than just that there's "some" .debug_info relocation in the fi...

...describing relative to the start of debug_info section >>>>>>>> saves us a few symbols :) >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 0002: >>>>>>>>> ref_addr_relocation.ll: >>>>>>>>> seems a bit vague in terms of how you test for the relocation. >>>>>>>>> I think it'd make more sense to test the assembly, than the reafobj output, >>>>>>>>> that way you can test that the correc...

...gt; symbol at the start of the debug_info section, or should we put a label at > the start of each CU? > Either way should work. But since we already have the section offset for each CU, describing relative to the start of debug_info section saves us a few symbols :) > > 0002: > ref_addr_relocation.ll: > seems a bit vague in terms of how you test for the relocation. I think > it'd make more sense to test the assembly, than the reafobj output, that > way you can test that the correct bytes have the relocation rather than > just that there's "some" .debug_info...

...the start of debug_info section >>>>>>>>> saves us a few symbols :) >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 0002: >>>>>>>>>> ref_addr_relocation.ll: >>>>>>>>>> seems a bit vague in terms of how you test for the >>>>>>>>>> relocation. I think it'd make more sense to test the assembly, than the >>>>>>>>>> reafobj output, that way you can test tha...

...section >>>>>>>>>> saves us a few symbols :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 0002: >>>>>>>>>>> ref_addr_relocation.ll: >>>>>>>>>>> seems a bit vague in terms of how you test for the >>>>>>>>>>> relocation. I think it'd make more sense to test the assembly, than the >>>>>>>>>>> reafobj output, that way you...

...section >>>>>>>>>> saves us a few symbols :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 0002: >>>>>>>>>>> ref_addr_relocation.ll: >>>>>>>>>>> seems a bit vague in terms of how you test for the >>>>>>>>>>> relocation. I think it'd make more sense to test the assembly, than the >>>>>>>>>>> reafobj output, that way you...

...>>>>>>> saves us a few symbols :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 0002: >>>>>>>>>>>> ref_addr_relocation.ll: >>>>>>>>>>>> seems a bit vague in terms of how you test for the >>>>>>>>>>>> relocation. I think it'd make more sense to test the assembly, than the >>>>>>>>>>>> reafobj output, t...

...>> saves us a few symbols :) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 0002: >>>>>>>>>>>>> ref_addr_relocation.ll: >>>>>>>>>>>>> seems a bit vague in terms of how you test for the >>>>>>>>>>>>> relocation. I think it'd make more sense to test the assembly, than the >>>>>>>>>>>>> reafo...

Ping -Manman On Fri, Oct 4, 2013 at 7:00 PM, Manman Ren <manman.ren at gmail.com> wrote: > > Hi All, > > The first patch adds support for ref_addr. > Most of it is from r176882, but instead of always using an integer for > ref_addr, we use label + offset for relocation on non-darwin platforms. > > The second patch is a modified version of r191792. > The main