Re: [Tinycc-devel] TinyCC REPL
Hi!
The code what I asked above:
v = ~SYM_EXTENDED;
if (v = SYM_EXTENDED) {
}
I think that a rigth code must be:
if (v = SYM_EXTENDED) {
}
v = ~SYM_EXTENDED;
I don't know if v can be negative, but the first version is wrong even
for the positive v (as I understand)
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC REPL
Hey Sergey, Good point. I use the expressesion v SYM_EXTENDED and (v ~SYM_EXTENDED) == v interchangeably, as they *mean* the exact same thing for an unsigned integer. I got the idea because inequalities are used with SYM_FIRST_ANOM, so I assumed that inequalities would be safe. I'll fix mine to bit checks. @Everybody, Might there be a subtle bug in tcc's anonymous symbol checking, since it uses inequalities rather than querying bits directly? David On Mon, May 18, 2015 at 6:52 AM, Sergey Korshunoff sey...@gmail.com wrote: 0x8000 is a sign bit. If v == 0x8000 then v 0x4000 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC REPL
David Mertens wrote: @Everybody, Might there be a subtle bug in tcc's anonymous symbol checking, since it uses inequalities rather than querying bits directly? No, not at all. Say, you think that potentially 268 million symbols in one source file could easily confuse anyone non-asperger and that you want to limit the number to at most 5, then you could change #define SYM_FIRST_ANOM 0x1000 to #define SYM_FIRST_ANOM 5 To the desired effect and without any problems, with the code written as is ;). --- gr ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] No lazy PLTGOT relocation for TinyCC generated executables
On May 18, 2015 11:17:35 PM GMT+08:00, Sergey Korshunoff sey...@gmail.com wrote: tries comparing the output of readelf -a for an hello world program but there are too many differences and I didn't spot anything obvious there is no .got.plt section in the tcc generated exe. gcc don't generate this section if bind_now. no (FLAGS attribute too. Doh, indeed. How could I miss that? Actually I know, the diff was basically all deletions followed by all additions so I focused on common sections. Anyway both sections (.got and .got.plt) have same access rights (WA) and the names shouldn't matter so does glibc changes it's behaviour if there is more than one section with (dynamic) relocations? Or does it check if a section is full of JUMP_SLOT only? I'll enable lazy relocation as part of the refactoring I'm doing as it's easier but will try to do an intermediary push as soon as I do it rather than wait to complete all the refactoring. Cheers, Thomas. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] No lazy PLTGOT relocation for TinyCC generated executables
Hi, On Thu, 21 May 2015, Thomas Preud'homme wrote: On May 18, 2015 11:17:35 PM GMT+08:00, Sergey Korshunoff sey...@gmail.com wrote: tries comparing the output of readelf -a for an hello world program but there are too many differences and I didn't spot anything obvious there is no .got.plt section in the tcc generated exe. gcc don't generate this section if bind_now. no (FLAGS attribute too. Doh, indeed. How could I miss that? Actually I know, the diff was basically all deletions followed by all additions so I focused on common sections. Anyway both sections (.got and .got.plt) have same access rights (WA) and the names shouldn't matter so does glibc changes it's behaviour if there is more than one section with (dynamic) relocations? Or does it check if a section is full of JUMP_SLOT only? No, the missing of .got.plt is a red herring (it's used to implement a security feature to isolate .got slots that can be written to also after program relocation from those can can't). The real problem is, that the dynamic linker only resolves relocations lazily that are consecutive and properly announced in the ELF dynamic section. Normal relocations are found by the DT_RELA/DT_RELASZ (DT_RELAENT) entries, they describe where in the ELF file relocations are found (note that sections are completely irrelevant for the loader). Then there's also an DT_JMPREL/DT_PLTRELSZ (DT_PLTREL) pair that describes where the _lazy_ relocations are to be found. This was for a RELA arch, a REL one is equivalent. So, if the latter is missing (and hence all relocs are bounded by the first pair) then all relocs are done eagerly. So, tcc needs to emit relocations a bit different: either sorting by type, then describing the JUMP_SLOT relocs with the DT_JMPREL pair (and exclude them from the DT_RELA pair), or keeping JUMP_SLOT and other relocs separate from the start, but still using the two pairs to describe lazy and non-lazy relocs. I'll enable lazy relocation as part of the refactoring I'm doing as it's easier but will try to do an intermediary push as soon as I do it rather than wait to complete all the refactoring. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
