Re: [PATCH V2] libelf/elf_end.c: check data_list.data.d.d_buf before free it
Hi Robert, On Fri, 2018-08-31 at 10:17 +0800, Robert Yang wrote: > Sorry, I can't make sure which ones is wrong, libqb, prelink or > elfutils, this > happens when cross compiling, and I've built more than 4 hunderds of packages, > libqb 1.0.3 is the only package which has the problem, I've also fixed > prelink, > but it is another segmentation fault error. I've reported this problem to > libqb > community, then they make another branch for libqb, and it works well without > any errors, the branch is topic-no-ldsection, and the commit is: > https://github.com/ClusterLabs/libqb/commit/358e0120d8cd288095907869d3f8da92937188a0 So, this is a separate issue? Or does the prelink problem also go away when using that commit/branch? > I've used gdb/valgrind to debug this segfault, but can't find prelink's > distinct > problem, the only problem I found is that elfutil's elf_end() free() a NULL > memory, so I made this patch. OK. So I believe that is because prelink's error handling seems wrong. It seems to assume it adding the ELF data buffer itself, so frees it, but the data actually seemed to come from elf_getdata, so shouldn't have been freed by prelink. Thanks, Mark
Re: Accessing String Table Indexes for .rodata
Thanks for replying.
I mean for example,
void myprintf(const char* ptr) {
printf("%p\n", ptr);
}
int main() {
myprintf("hello world");
}
Let's say the output is 0x403DE.
Does it mean that Elf64_Shdr::sh_addr of the string table (of .rodata)
+ the offset of "hello word" within the string table is guaranteed to
be the virtual address 0x403DE? As I am not sure whether virtual
memory addresses of all string literals are defined/calculated when
ELF is created.
Thanks!
Cheers
On Fri, Aug 31, 2018 at 3:54 AM Mark Wielaard wrote:
>
> On Tue, Aug 21, 2018 at 12:16:09AM +0800, Henry C wrote:
> > Tho, I have no clue how to get the index to each of the string in the
> > string table above.
>
> The .rodata section isn't just a simple ELF string table.
> Otherwise you could use elf_strptr (see libelf.h) to index through them.
> But .rodata also contains other read only data. There is no simple
> ELF based index for just the strings.
>
> > And one more related question is that I noticed the virtual memory
> > addresses of the string literals are same as the offsets to the
> > (executable) file. Is it intended? Guaranteed?
>
> If you mean that the sh_offset and sh_addr are the same then that
> not guaranteed. The mapping from file offset to addresses for allocated
> sections is given by the program headers. You can see how they are
> mapped exactly using eu-readelf -l.
>
> Cheers,
>
> Mark
Re: Accessing String Table Indexes for .rodata
On Fri, 2018-08-31 at 19:07 +0800, Henry C wrote:
> Thanks for replying.
>
> I mean for example,
> void myprintf(const char* ptr) {
> printf("%p\n", ptr);
> }
>
> int main() {
> myprintf("hello world");
> }
>
> Let's say the output is 0x403DE.
>
> Does it mean that Elf64_Shdr::sh_addr of the string table (of
> .rodata)
> + the offset of "hello word" within the string table is guaranteed to
> be the virtual address 0x403DE? As I am not sure whether virtual
> memory addresses of all string literals are defined/calculated when
> ELF is created.
No, that is not guaranteed. How data in an ELF file is mapped into
memory is determined by the program headers (not the section headers).
See also the picture showing the different ELF file data views in https
://en.wikipedia.org/wiki/Executable_and_Linkable_Format
Cheers,
Mark
Re: Accessing String Table Indexes for .rodata
Hi Mark,
I just dumped out my executable (code was in my very first email):
$ eu-readelf -l myexec
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flg Align
PHDR 0x40 0x00400040 0x00400040
0x0001f8 0x0001f8 R E 0x8
INTERP 0x000238 0x00400238 0x00400238
0x1c 0x1c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x00 0x0040 0x0040
0x00079c 0x00079c R E 0x20
LOAD 0x000de8 0x00600de8 0x00600de8
0x000247 0x000248 RW 0x20
DYNAMIC0x000df8 0x00600df8 0x00600df8
0x000200 0x000200 RW 0x8
NOTE 0x000254 0x00400254 0x00400254
0x44 0x44 R 0x4
GNU_EH_FRAME 0x00063c 0x0040063c 0x0040063c
0x44 0x44 R 0x4
GNU_STACK 0x00 0x 0x
0x00 0x00 RW 0x10
GNU_RELRO 0x000de8 0x00600de8 0x00600de8
0x000218 0x000218 R 0x1
Section to Segment mapping:
Segment Sections...
00
01 [RO: .interp]
02 [RO: .interp .note.ABI-tag .note.gnu.build-id .gnu.hash
.dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init
.plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame]
03 [RELRO: .init_array .fini_array .dynamic .got] .got.plt .data .bss
04 [RELRO: .dynamic]
05 [RO: .note.ABI-tag .note.gnu.build-id]
06 [RO: .eh_frame_hdr]
07
08 [RELRO: .init_array .fini_array .dynamic .got]
By looking at the output and the wiki link, the program headers do
contain virtual addresses but nothing explicit about .rodata. How can
I use libelf to figure the correct virtual memory address to "hello
world"?
But if I print out Elf64_Shdr::sh_addr (.rodata section header) +
offset to "hello world" in .rodata, I do see the output matches the
output of printf("%p\n", "hello world");
As you mentioned, it is not guaranteed, I wonder under what situation
Elf64_Shdr::sh_addr won't represent the virtual address of the
beginning of .rodata section.
Thanks in advance!
On Fri, Aug 31, 2018 at 7:33 PM Mark Wielaard wrote:
>
> On Fri, 2018-08-31 at 19:07 +0800, Henry C wrote:
> > Thanks for replying.
> >
> > I mean for example,
> > void myprintf(const char* ptr) {
> > printf("%p\n", ptr);
> > }
> >
> > int main() {
> > myprintf("hello world");
> > }
> >
> > Let's say the output is 0x403DE.
> >
> > Does it mean that Elf64_Shdr::sh_addr of the string table (of
> > .rodata)
> > + the offset of "hello word" within the string table is guaranteed to
> > be the virtual address 0x403DE? As I am not sure whether virtual
> > memory addresses of all string literals are defined/calculated when
> > ELF is created.
>
> No, that is not guaranteed. How data in an ELF file is mapped into
> memory is determined by the program headers (not the section headers).
> See also the picture showing the different ELF file data views in https
> ://en.wikipedia.org/wiki/Executable_and_Linkable_Format
>
> Cheers,
>
> Mark
Re: Accessing String Table Indexes for .rodata
On Fri, 2018-08-31 at 20:35 +0800, Henry C wrote: > As you mentioned, it is not guaranteed, I wonder under what situation > Elf64_Shdr::sh_addr won't represent the virtual address of the > beginning of .rodata section. Try creating a shared library or compile your application with -pie to make an ELF executable that isn't mapped at a fixed address. Also not all ELF files will have a section table, some might only have program headers. In that case you cannot even locate the .rodata section since it will just be part of some segment.
