http://bugs.winehq.org/show_bug.cgi?id=20509
Summary: gdb proxy mode: random reply to Offsets query? Product: Wine Version: 1.1.32 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: winedbg AssignedTo: wine-bugs@winehq.org ReportedBy: pebolle@tiscali.nl
0) In gdb proxy mode the replies to "query packets" are constructed in programs/winedbg/gdbproxy.c:packet_query(). The reply to qOffsets is based on gdbctx->wine_segs (that reply has the form: Text=[...];Data=[...];Bss=[...]).
1) As far as I can see gdbctx->wine_segs is never properly set, so the reply seems to be (basically) random.
2) If the above is correct, the code needs a patch. I have no idea to what value(s) gdbctx->wine_segs should be set, so I can't draft that patch.
http://bugs.winehq.org/show_bug.cgi?id=20509
--- Comment #1 from Paul Bolle pebolle@tiscali.nl 2009-10-29 16:24:15 --- (In reply to comment #0)
- As far as I can see gdbctx->wine_segs is never properly set, so the reply
seems to be (basically) random.
- If the above is correct, the code needs a patch. I have no idea to what
value(s) gdbctx->wine_segs should be set, so I can't draft that patch.
A simple printf() at the top of gdb_remote() trivially proves that wine_segs will not be changed after gdbctx is defined (and still holds random data once it is used).
Someone with a suggestion for a solution?
http://bugs.winehq.org/show_bug.cgi?id=20509
Paul Bolle pebolle@tiscali.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|gdb proxy mode: random |gdb proxy mode: random |reply to Offsets query? |reply to Offsets query
http://bugs.winehq.org/show_bug.cgi?id=20509
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.pouech@orange.fr
--- Comment #2 from Eric Pouech eric.pouech@orange.fr 2009-11-01 05:24:23 --- first of all wine_segs[0..2] must be initialized to 0 in gdb_init_context
it would be rather straightforward to get a correct value for wine_segs[0] (aka code) as it's the base address of the main module, which we could get in gdb_startup
however, wine_segs[1] (aka data) would be more difficult to get note, it seems that when Data=XXX, BSS=XXX is ignored by gdb
moreover, latest gdb version also use CodeSeg, DataSeg (instead of Code, Data) in order to provide linear addresses instead of offsets for relocation, which will be handier in our case
HTH A+
http://bugs.winehq.org/show_bug.cgi?id=20509
--- Comment #3 from Paul Bolle pebolle@tiscali.nl 2009-11-01 06:49:00 --- (In reply to comment #2)
first of all wine_segs[0..2] must be initialized to 0 in gdb_init_context
0) Only if they're not set to something meaningful before they're used. 1) The code will currently return an error packet if all three are zero.
it would be rather straightforward to get a correct value for wine_segs[0] (aka code) as it's the base address of the main module,
2) Wine's main module?
which we could get in gdb_startup
however, wine_segs[1] (aka data) would be more difficult to get note, it seems that when Data=XXX, BSS=XXX is ignored by gdb
3) According to gdb's documentation. gdb's code requires Bss=[...], even though its value must be equal to Data=[...]. Rather silly.
moreover, latest gdb version also use CodeSeg, DataSeg (instead of Code, Data) in order to provide linear addresses instead of offsets for relocation, which will be handier in our case
4) How can CodeSeg and DataSeg be determined?
http://bugs.winehq.org/show_bug.cgi?id=20509
--- Comment #4 from Eric Pouech eric.pouech@orange.fr 2009-11-02 13:56:52 --- (In reply to comment #3)
- The code will currently return an error packet if all three are zero.
yes, but that what you'd expect if the main exec is not relocated.
- Wine's main module?
yes
- According to gdb's documentation. gdb's code requires Bss=[...], even though
its value must be equal to Data=[...]. Rather silly.
agreed
- How can CodeSeg and DataSeg be determined?
look at dbg_get_debuggee_info in programs/winedbg/winedbg.c, it'll return a module info for the wine loader...
A+
http://bugs.winehq.org/show_bug.cgi?id=20509
--- Comment #5 from Paul Bolle pebolle@tiscali.nl 2009-11-04 08:08:57 --- (In reply to comment #4)
(In reply to comment #3)
- The code will currently return an error packet if all three are zero.
yes, but that what you'd expect if the main exec is not relocated.
As far as I can see (untested, however) that will generate a gdb warning: if (buf[0] == 'E') { warning (_("Remote failure reply: %s"), buf); return; }
So to me it looks better to return three zero offsets explicitly (or return nothing, which gdb seems to handle juts fine, silently).
http://bugs.winehq.org/show_bug.cgi?id=20509
--- Comment #6 from Paul Bolle pebolle@tiscali.nl 2010-08-28 14:52:42 CDT --- (In reply to comment #5)
So to me it looks better to return three zero offsets explicitly (or return nothing, which gdb seems to handle just fine, silently).
This is precisely what happens since commit a116f78dedaf05a8b3f44bf5d56a5b76faaccacc ("winedbg: In proxy mode, correctly init the wine_segs fields."). Thanks.
I guess we can close this bug. If someone can think of a valid reason to return more meaningful values to an Offsets query they could open a new report. (I can't think of a reason right now. Actually, I can't even remember how I first noticed this bug. And it's been less than a year ...)
http://bugs.winehq.org/show_bug.cgi?id=20509
Eric Pouech eric.pouech@orange.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #7 from Eric Pouech eric.pouech@orange.fr 2011-04-24 07:43:02 CDT --- init of segs fixes the behavior
http://bugs.winehq.org/show_bug.cgi?id=20509
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2011-04-29 13:16:19 CDT --- Closing bugs fixed in 1.3.19.