* [RFC] problem with read_memory_string (reads 8 bytes at a time)
@ 2009-04-08 18:27 Joel Brobecker
2009-04-08 19:01 ` Thiago Jung Bauermann
0 siblings, 1 reply; 4+ messages in thread
From: Joel Brobecker @ 2009-04-08 18:27 UTC (permalink / raw)
To: gdb-patches
Hello,
I did what I thought would be a nice cleanup in ada-lang.c last weekend,
by deleting a local function (extract_string), and replacing it by a call
to read_memory_string instead. This works fine most of the time, but
nightly testing did reveal a problem with that function on powerpc-elf.
(gdb) start
Cannot access memory at address 0x1002e8
Here is what happens:
1. The "start" commands needs to know that the name of the "main"
program is. As a result, we call ada_main_name, which finds
the symbol that points us to the string containing that main
name.
2. To read that name, we call read_memory_string now, and this
routine performs strings reads 8 bytes at a time.
The problem is that our string is at the end of our .rodata section.
The string is 8 bytes long, and sits at 0x1002e0. The .rodata section
ends at 0x001102ec. So here's what we end up doing:
a. Read 8 bytes from 0x1002e0 - no problem.
But we haven't read the \0 yet, so we keep going.
b. Read 8 bytes from 0x1002e0 + 8 = 0x1002e8:
i. The section ends at 0x001102ec, so bfd returns only 4 bytes read.
ii. We find out that only 4 bytes were read, so we still need to
read another 4 bytes for the 8byte read to be complete
iii. the next 4byte read doesn't find a section from which to
read the 4bytes, and so returns 0 signifying an error.
I don't really know how to fix this issue except by reading the string
one byte at a time :-(. Any suggestion?
Thanks,
--
Joel
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [RFC] problem with read_memory_string (reads 8 bytes at a time)
2009-04-08 18:27 [RFC] problem with read_memory_string (reads 8 bytes at a time) Joel Brobecker
@ 2009-04-08 19:01 ` Thiago Jung Bauermann
2009-04-08 21:26 ` Joel Brobecker
0 siblings, 1 reply; 4+ messages in thread
From: Thiago Jung Bauermann @ 2009-04-08 19:01 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
El mié, 08-04-2009 a las 11:26 -0700, Joel Brobecker escribió:
> b. Read 8 bytes from 0x1002e0 + 8 = 0x1002e8:
> i. The section ends at 0x001102ec, so bfd returns only 4 bytes read.
> ii. We find out that only 4 bytes were read, so we still need to
> read another 4 bytes for the 8byte read to be complete
> iii. the next 4byte read doesn't find a section from which to
> read the 4bytes, and so returns 0 signifying an error.
>
> I don't really know how to fix this issue except by reading the string
> one byte at a time :-(. Any suggestion?
I suggest using target_read_string. If I understand its code correctly,
it handles the corner case you hit.
I thought that valprint.c:read_string also handled that, but now that I
read the code again, it looks like it would fail too. :-(
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] problem with read_memory_string (reads 8 bytes at a time)
2009-04-08 19:01 ` Thiago Jung Bauermann
@ 2009-04-08 21:26 ` Joel Brobecker
2009-04-08 22:18 ` Thiago Jung Bauermann
0 siblings, 1 reply; 4+ messages in thread
From: Joel Brobecker @ 2009-04-08 21:26 UTC (permalink / raw)
To: Thiago Jung Bauermann; +Cc: gdb-patches
> I suggest using target_read_string. If I understand its code correctly,
> it handles the corner case you hit.
Thanks for the tip!
It looks like it does, indeed - although a little ineffectively:
Once it failed to read a 4byte block, it tries reading 1 byte.
If that works, then it tries 3bytes, which won't work again,
and thus try 1 byte one more time. If that works, then it'll read
2 bytes, etc. I don't think this is a big deal, though.
That being said, I am wondering why we have more than 1 routine
to read strings... Is there something we should do?
(I will change my code to use target_read_string for now - this won't
help testing the case were we cross a boundary because the \0 is
byte 0 of the last 4 bytes of my section, and that section is 4bytes-
aligned).
--
Joel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC] problem with read_memory_string (reads 8 bytes at a time)
2009-04-08 21:26 ` Joel Brobecker
@ 2009-04-08 22:18 ` Thiago Jung Bauermann
0 siblings, 0 replies; 4+ messages in thread
From: Thiago Jung Bauermann @ 2009-04-08 22:18 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
El mié, 08-04-2009 a las 14:26 -0700, Joel Brobecker escribió:
> > I suggest using target_read_string. If I understand its code correctly,
> > it handles the corner case you hit.
>
> Thanks for the tip!
>
> It looks like it does, indeed - although a little ineffectively:
> Once it failed to read a 4byte block, it tries reading 1 byte.
> If that works, then it tries 3bytes, which won't work again,
> and thus try 1 byte one more time. If that works, then it'll read
> 2 bytes, etc. I don't think this is a big deal, though.
Well, it's not efficient for your case, but it's efficient for the case
where three bytes out of a 4 byte "bite" were good. The next try will
read those 3 bytes and off you go...
> That being said, I am wondering why we have more than 1 routine
> to read strings... Is there something we should do?
Yes, I wondered the same when I was implementing LA_GET_STRING. I
believe we can consolidate those routines. I just added a new item to
the ProjectIdeas wiki page, under the "Internals" section.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-04-08 22:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-08 18:27 [RFC] problem with read_memory_string (reads 8 bytes at a time) Joel Brobecker
2009-04-08 19:01 ` Thiago Jung Bauermann
2009-04-08 21:26 ` Joel Brobecker
2009-04-08 22:18 ` Thiago Jung Bauermann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox