search for: jumptabledatasection

...seems to me that your patch changes the ARM backend to optionally handle jump tables in a way that is at least very similar to the default behavior, but you have implemented it without using the existing code. Did you consider implementing it using the LLVM defaults? Using TargetAsmInfo::JumpTableDataSection is one piece of that, but there is more. As a start, you could change ARMJITInfo::hasCustomJumpTables and the "Custom" argument to setOperationAction for ISD::BR_JT in the ARMTargetLowering constructor to be conditional on your new flag. I'm sure there is more required tha...

...>> > >>> I thought it would be nice to group all the jumptables together. > >>> But as long as it stays configurable, I am fine to change the > >>> default > >>> to ".data". > >> > >> There is already a TargetAsmInfo::JumpTableDataSection. Why not just > >> use that? > > > > Nice find. I will use that and possible change the current setting, > > ".const", if it does not work, > > > >>> > >>>> Is this necessary? Why not just put it in the normal data section? >...

...ome assumptions about the format of each jumptable entry (e.g. 32bit absolute addresses) so this cannot be changed easily afterwards. Having the default jumtables and the out of line version diverge too much and have different code path may also not be such a good idea. > Using TargetAsmInfo::JumpTableDataSection is one piece of that, but there > is more. As a start, you could change ARMJITInfo::hasCustomJumpTables and > the "Custom" argument to setOperationAction for ISD::BR_JT in the > ARMTargetLowering constructor to be conditional on your new flag. I'm sure > there is more re...

...cl::init(".data.jtab")); >> + > > I thought it would be nice to group all the jumptables together. > But as long as it stays configurable, I am fine to change the default > to ".data". There is already a TargetAsmInfo::JumpTableDataSection. Why not just use that? > >> Is this necessary? Why not just put it in the normal data section? >> Also "outline" jumptable seems like a strange term. Can you think of >> something else? > > > Yes, that is a tough one. How about "NonInline" inste...

...            cl::init(".data.jtab")); >>> + >> >> I thought it would be nice to group all the jumptables together. >> But as long as it stays configurable, I am fine to change the default >> to ".data". > > There is already a TargetAsmInfo::JumpTableDataSection. Why not just > use that? Nice find. I will use that and possible change the current setting, ".const", if it does not work, >> >>> Is this necessary? Why not just put it in the normal data section? >>> Also "outline" jumptable seems like a strange t...

On Sat, Jun 6, 2009 at 4:51 PM, Evan Cheng<evan.cheng at apple.com> wrote: > +cl::opt<std::string> FlagJumpTableSection("jumptable-section", > +                                           cl::init(".data.jtab")); > + I thought it would be nice to group all the jumptables together. But as long as it stays configurable, I am fine to change the default to

...;)); >>>> + >>> >>> I thought it would be nice to group all the jumptables together. >>> But as long as it stays configurable, I am fine to change the >>> default >>> to ".data". >> >> There is already a TargetAsmInfo::JumpTableDataSection. Why not just >> use that? > > Nice find. I will use that and possible change the current setting, > ".const", if it does not work, > >>> >>>> Is this necessary? Why not just put it in the normal data section? >>>> Also "outline&quot...

...nce burden, and in this case, it seems like we can easily avoid it. It also helps leverage the existing code. For example, I didn't look too closely, but with my patch, compiling with -relocation-model=pic seemed to do the right thing. > > Why did you change the default value for JumpTableDataSection? Jump > tables really should not go into .data. That is a security hole. > They should be read-only. > > I changed that too so the data goes into the default .rodata now. > I am not sure where .rodata lives. if it lives in the text *segment* > you get better protection but...

...in this case, it seems like we can easily avoid it. > > > It also helps leverage the existing code. For example, I didn't look too closely, but with my patch, compiling with -relocation-model=pic seemed to do the right thing. > > >> Why did you change the default value for JumpTableDataSection? Jump >> tables really should not go into .data. That is a security hole. They >> should be read-only. >> > > I changed that too so the data goes into the default .rodata now. > I am not sure where .rodata lives. if it lives in the text *segment* > you get better pr...