This is the mail archive of the
mailing list for the GDB project.
Re: how to make gdb happy with my linkmap
- From: "Mathieu Lacage" <mathieu dot lacage at gmail dot com>
- To: gdb at sourceware dot org
- Date: Mon, 12 Jan 2009 16:08:13 +0100
- Subject: Re: how to make gdb happy with my linkmap
- References: <email@example.com> <20081218214854.GA7706@caradoc.them.org> <firstname.lastname@example.org> <20081218221005.GA9012@caradoc.them.org> <email@example.com> <20081226125329.GA12783@caradoc.them.org> <firstname.lastname@example.org>
Just in case it helps anyone, since I did not really have time to
investigate the gdb issues, I came up with the attached elf editor
which replaces the content of PT_INTERP. Eventually, I will have to
deal with gdb but, not now :)
On Mon, Jan 5, 2009 at 3:58 PM, Mathieu Lacage <email@example.com> wrote:
>> Does it work any better with ld.so? I doubt it - GDB doesn't do
> It does not seem to work any better with ld-linux.so.2. I tried to
> look into this a bit more but I did not make much progress. Here is
> what I get:
> mathieu@mathieu-boulot:~/code/elf-loader$ gdb ./ldso
> GNU gdb 6.8-debian
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i486-linux-gnu"...
> (gdb) b stage1
> Breakpoint 1 at 0x944: file ldso.c, line 304.
> (gdb) r ./hello
> Starting program: /home/mathieu/code/elf-loader/ldso ./hello
> Program exited normally.
> What I find weird is:
> 1) mathieu@mathieu-boulot:~/code/elf-loader$ readelf -s ./ldso |grep stage1
> 225: 00000932 135 FUNC GLOBAL HIDDEN 6 stage1
> mathieu@mathieu-boulot:~/code/elf-loader$ readelf -l ./ldso
> Elf file type is DYN (Shared object file)
> Entry point 0x932
> There are 6 program headers, starting at offset 52
> i.e., stage1 is located at offset 0x932, and not 0x944 so, I can't
> figure out where the 0x944 displayed by gdb is coming from. I also
> find it surprising that gdb is actually trying to set a breakpoint at
> address 0x944: this is a pie binary so, gdb should know that the
> address will be known only once the program is run....
> To summarize, 2 questions:
> 1) what do I need to do to make gdb _not_ attempt to really set the
> breakpoint before the program is run ?
> 2) why is gdb using 0x944 and not 0x932 ?
> I am shooting a bit in the dark here, obviously.
> Mathieu Lacage <firstname.lastname@example.org>
Mathieu Lacage <email@example.com>
int main (int argc, char *argv)
const char *filename = argv;
int fd = open (filename, O_RDWR);
ssize_t bytes_read = read (fd, &header, sizeof (header));
if (bytes_read != sizeof (header))
ElfW(Phdr) *ph = malloc (header.e_phnum * header.e_phentsize);
if (ph == 0)
if (lseek (fd, header.e_phoff, SEEK_SET) == -1)
if (read (fd, ph, header.e_phnum * header.e_phentsize) != header.e_phnum * header.e_phentsize)
for (i = 0; i < header.e_phnum; i++)
if (ph[i].p_type == PT_INTERP)
if (strlen (argv) + 1> ph[i].p_filesz)
if (lseek (fd, ph[i].p_offset, SEEK_SET) == -1)
char *interp = malloc (ph[i].p_filesz);
memset (interp, 0, ph[i].p_filesz);
memcpy (interp, argv, strlen (argv));
if (write (fd, argv, ph[i].p_filesz) != ph[i].p_filesz)
if (lseek (fd, header.e_phoff + ((long)&ph[i].p_filesz - (long)ph), SEEK_SET) == -1)
ElfW(Xword) filesz = strlen (argv)+1;
if (write (fd, &filesz, sizeof(filesz)) != sizeof(filesz))
if (lseek (fd, header.e_phoff + ((long)&ph[i].p_memsz-(long)ph), SEEK_SET) == -1)
ElfW(Xword) memsz = strlen (argv)+1;
if (write (fd, &memsz, sizeof(memsz)) != sizeof(memsz))